Part of #704.
Reported symptom
Owner: "the yes button doesn't need to be so big."
Code evidence
The Level 1 "Yes" confirm button (QuestionFeed.tsx:1330-1340) is rendered with className="primary big block". Btn (QuestionFeed.tsx:355-416) is the shared base for every button on this page: base min-height 44px, font-size 15px. The .big modifier (lines 376-380) bumps that to font-size 17px, font-weight 800, padding 10px 20px, and .block (lines 382-384) sets width:100%. The Yes button is the only button on this screen carrying both modifiers.
Its three siblings in ActionGrid immediately below it - "Not sure" (1342-1349), "No, different printing" (1350-1357), "Skip" (1358-1365) - use only className="secondary" or "ghost" (no .big, no .block), and sit inside ActionGrid (QuestionFeed.tsx:427-441), a grid with columns sized via repeat(auto-fit, minmax(clamp(120px, 34cqi, 180px), 1fr)) - i.e. each capped well under full width and at the base 15px/600-weight text. So the visual hierarchy is: one full-width, 17px/800-weight, extra-padded button, directly above three same-row buttons roughly a third that width at smaller, lighter text - the disparity is a direct, measurable product of the className stacking, not a subjective impression.
Confirmed / Refuted / Inconclusive
Confirmed. The Yes button combines both size-increasing Btn modifiers (.big and .block) while every other action button on the same screen uses neither.
Scope
Touches the className on the Level 1 Yes button (QuestionFeed.tsx:1330) and/or the Btn/.big/.block modifier definitions themselves (QuestionFeed.tsx:355-416) if the fix is a new, smaller variant rather than just dropping a modifier from this one button. Consider whether removing .block (full-width) alone is sufficient, or whether .big (font/padding) also needs to shrink - the owner's complaint ("doesn't need to be so big") suggests the latter.
Layout-pass coupling
Small, mostly isolated change (one className plus possibly a shared Btn variant), but touches the same Btn/ActionGrid primitives that the hover-zoom item's CandidateButton work sits alongside in cardPanel.tsx/QuestionFeed.tsx's shared styled-component set - low risk to sequence independently, but worth a single pass since both are quick className/variant edits in the same file.
Part of #704.
Reported symptom
Owner: "the yes button doesn't need to be so big."
Code evidence
The Level 1 "Yes" confirm button (QuestionFeed.tsx:1330-1340) is rendered with className="primary big block". Btn (QuestionFeed.tsx:355-416) is the shared base for every button on this page: base min-height 44px, font-size 15px. The .big modifier (lines 376-380) bumps that to font-size 17px, font-weight 800, padding 10px 20px, and .block (lines 382-384) sets width:100%. The Yes button is the only button on this screen carrying both modifiers.
Its three siblings in ActionGrid immediately below it - "Not sure" (1342-1349), "No, different printing" (1350-1357), "Skip" (1358-1365) - use only className="secondary" or "ghost" (no .big, no .block), and sit inside ActionGrid (QuestionFeed.tsx:427-441), a grid with columns sized via repeat(auto-fit, minmax(clamp(120px, 34cqi, 180px), 1fr)) - i.e. each capped well under full width and at the base 15px/600-weight text. So the visual hierarchy is: one full-width, 17px/800-weight, extra-padded button, directly above three same-row buttons roughly a third that width at smaller, lighter text - the disparity is a direct, measurable product of the className stacking, not a subjective impression.
Confirmed / Refuted / Inconclusive
Confirmed. The Yes button combines both size-increasing Btn modifiers (.big and .block) while every other action button on the same screen uses neither.
Scope
Touches the className on the Level 1 Yes button (QuestionFeed.tsx:1330) and/or the Btn/.big/.block modifier definitions themselves (QuestionFeed.tsx:355-416) if the fix is a new, smaller variant rather than just dropping a modifier from this one button. Consider whether removing .block (full-width) alone is sufficient, or whether .big (font/padding) also needs to shrink - the owner's complaint ("doesn't need to be so big") suggests the latter.
Layout-pass coupling
Small, mostly isolated change (one className plus possibly a shared Btn variant), but touches the same Btn/ActionGrid primitives that the hover-zoom item's CandidateButton work sits alongside in cardPanel.tsx/QuestionFeed.tsx's shared styled-component set - low risk to sequence independently, but worth a single pass since both are quick className/variant edits in the same file.