feat: update progress bar default fill to horizontal gradient

[camsimony]

Description

Fix the Sage progress bar gradient implementation to address GitHub comments about CSS selector logic preventing legitimate use of #ff3e15 as a custom color. The solution replaces complex CSS attribute selectors with a class-based approach that follows existing Sage component patterns.

Key changes:

• Added sage-progress-bar__value--custom class when color differs from default MERCURY_500
• Updated CSS to target the new class instead of &[style*="--progress-bar-value-color"] selector
• Modified both React and Rails components for consistency
• Ensures default progress bars show gradient while custom colors (including #ff3e15) display correctly

Screenshots

Before	After

Testing in sage-lib

Critical testing areas:

1. Navigate to http://localhost:4000/pages/component/progress_bar?tab=preview
2. Verify default progress bars (first 3 examples) display the horizontal gradient (#FDA4AF → #FF3E14)
3. Confirm custom color progress bars (last 2 examples) show solid custom colors without gradient
4. Test edge case: Create a progress bar with color: "#ff3e15" and verify it shows solid red, not gradient
5. Verify the sage-progress-bar__value--custom class is only applied when color differs from default

Key verification points:

• Default progress bars: No custom class → shows gradient
• Custom color progress bars: Has custom class → shows solid color from CSS variable
• The logic color !== ProgressBar.COLORS.MERCURY_500 works correctly

Testing in kajabi-products

1. (LOW) Progress bar gradient implementation updated to use class-based approach instead of CSS attribute selectors.
   • Test progress bars in course creation flows to verify default gradient displays
   • Check member dashboard progress indicators still show custom colors correctly
   • Verify upload progress bars maintain their custom styling
   • Test assessment completion indicators work as expected
   • Confirm no visual regressions in admin analytics progress displays

Areas to verify no adverse effects:

• Course progress indicators
• Upload progress bars
• Assessment completion indicators
• Dashboard analytics progress displays
• Any components using #ff3e15 as a legitimate custom color

Related

• Addresses GitHub comments from pixelflips about CSS selector preventing legitimate use of #ff3e15
• Jira ticket: DSS-1497
• Pine Design System PR: feat: update progress bar default fill to horizontal gradient pine#515
• Link to Devin run: https://app.devin.ai/sessions/f76dcde5eca0423a9fcdba1671311c27
• Requested by: @cameronsimony

Review Checklist

Critical areas requiring human review:

• CSS logic: Verify &:not(.sage-progress-bar__value--custom) and &.sage-progress-bar__value--custom selectors work correctly
• Component consistency: Confirm React and Rails components use identical logic for applying custom class
• Default color comparison: Review color !== ProgressBar.COLORS.MERCURY_500 logic handles edge cases correctly
• Visual verification: Test that gradient appears for defaults and custom colors override properly
• Cross-browser compatibility: Verify gradient displays correctly across browsers
• Performance impact: Check if class-based approach affects rendering performance

⚠️ Important Notes:

• Local asset compilation failed due to Node.js compatibility issues, limiting visual verification during development
• This approach follows existing Sage patterns (similar to sage-avatar__badge--custom-bg)
• The change specifically addresses preventing #ff3e15 from being blocked as a custom color

[devin-ai-integration]

Original prompt from cameron.simony

Hey Devin,

I'd like you to update the default Progress Bar fill color from a solid red (#FF3E14) to a horizontal gradient (#FDA4AF → #FF3E14) in both the Sage and Pine design systems. This change should only affect the default variant of the progress bar while preserving all other functionality.

## Task Details
- Change the default progress bar fill from solid red (#FF3E14) to a linear gradient
- Gradient spec: #FDA4AF (left) → #FF3E14 (right)
- Gradient direction: horizontal (left to right)
- Only modify the default variant; custom color variants should remain unchanged
- Ensure percentage labels and tooltips remain unaffected

## Files to Modify

### Sage Design System:
- Path: `packages/sage-assets/lib/stylesheets/components/_progress_bar.scss`
- Current implementation: `.sage-progress-bar__value` element with `background-color: var(--progress-bar-value-color, var(--pine-color-brand))`
- You'll need to update this to conditionally apply the gradient when no custom color is set

### Pine Design System:
- Path: `libs/core/src/components/pds-progress/pds-progress.scss`
- Current implementation: Uses browser-specific pseudo-elements (`progress::-webkit-progress-value` and `progress::-moz-progress-bar`) with `background-color: var(--color-progress-fill, var(--pine-color-brand))`
- You'll need to update both pseudo-elements to ensure cross-browser compatibility

## Implementation Considerations
As you implement this, please consider these design decisions:
1. Should the gradient colors be implemented as CSS variables for future flexibility?
2. How should the gradient direction be handled in RTL layouts?
3. Is there a preferred fallback color for browsers that don't support gradients?
4. Should documentation be updated with examples of the new default style?
5. Should we consider this gradient as a design pattern to apply to other components?

When you create the PR, please include the Jira ticket ID (DSS-1497) in the PR description.

Looking forward to seeing your im... (13 chars truncated...)

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[camsimony]

@pixelflips @QuintonJason it made another PR for the same thing in Pine. I can't add you as reviewers for some reason. here's the link: Kajabi/pine#515

[pixelflips]

The code here seems outdated. Probably needs a rebase.

[github-actions]

Dependency Review

The following issues were found:

• ✅ 0 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ⚠️ 5 package(s) with unknown licenses.

See the Details below.

License Issues

docs/package.json

Package	Version	License	Issue Type
@kajabi/sage-packs	^6.2.20	Null	Unknown License

packages/sage-packs/package.json

Package	Version	License	Issue Type
@kajabi/sage-assets	^6.2.18	Null	Unknown License
@kajabi/sage-react	^6.2.20	Null	Unknown License
@kajabi/sage-system	^6.2.18	Null	Unknown License

packages/sage-react/package.json

Package	Version	License	Issue Type
@kajabi/sage-assets	^6.2.18	Null	Unknown License

Denied Licenses: LGPL-2.0, AAL, Adobe-2006, Afmparse, Artistic-1.0, Artistic-1.0-cl8, Artistic-1.0-Perl, Beerware, blessing, Borceux, CECILL-B, ClArtistic, Condor-1.1, Crossword, CrystalStacker, diffmark, DOC, EFL-1.0, EFL-2.0, Fair, FSFUL, FSFULLR, Giftware, HPND, IJG, Leptonica, LPL-1.0, LPL-1.02, MirOS, mpich2, NASA-1.3, NBPL-1.0, Newsletr, NLPL, NRL, OGTSL, OLDAP-1.1, OLDAP-1.2, OLDAP-1.3, OLDAP-1.4, psutils, Qhull, Rdisc, RSA-MD, Spencer-86, Spencer-94, TU-Berlin-1.0, TU-Berlin-2.0, Vim, W3C-19980720, W3C-20150513, Wsuipa, WTFPL, xinetd, Zed, Zend-2.0, ZPL-1.1, AGPL-1.0-only, AGPL-1.0-or-later, AGPL-3.0-only, AGPL-3.0-or-later, APSL-1.0, APSL-1.1, APSL-1.2, APSL-2.0, CPAL-1.0, EUPL-1.0, EUPL-1.1, EUPL-1.2, NPOSL-3.0, OSL-1.0, OSL-1.1, OSL-2.0, OSL-2.1, OSL-3.0, RPSL-1.0, SSPL-1.0, CAL-1.0, CAL-1.0-Combined-Work-Exception, Parity-6.0.0, Parity-7.0.0, RPL-1.1, RPL-1.5, EPL-1.0, EPL-2.0, ErlPL-1.1, IPL-1.0, LGPL-2.0-only, LGPL-2.0-or-later, LGPL-2.1-only, LGPL-2.1-or-later, LGPL-2.1, LGPL-3.0-only, LGPL-3.0-or-later, LGPL-3.0, MPL-1.0, MPL-1.1, MPL-2.0, MPL-2.0-no-copyleft-exception, MS-RL, SPL-1.0, BSD-Protection, copyleft-next-0.3.0, copyleft-next-0.3.1, GPL-1.0-only, GPL-1.0-or-later, GPL-1.0, GPL-2.0-only, GPL-2.0-or-later, GPL-2.0, GPL-3.0-only, GPL-3.0-or-later, GPL-3.0, QPL-1.0, Sleepycat

Scanned Manifest Files

docs/package.json

• @kajabi/sage-packs@^6.2.20
• @kajabi/sage-packs@^6.2.16

package.json

• @pine-ds/icons@^9.9.0
• @pine-ds/icons@^9.3.0

packages/sage-packs/package.json

• @kajabi/sage-assets@^6.2.18
• @kajabi/sage-react@^6.2.20
• @kajabi/sage-system@^6.2.18
• @kajabi/sage-assets@^6.2.16
• @kajabi/sage-react@^6.2.16
• @kajabi/sage-system@^6.2.16

packages/sage-react/package.json

• @kajabi/sage-assets@^6.2.18
• @kajabi/sage-assets@^6.2.16

yarn.lock

• @pine-ds/icons@9.9.0
• @pine-ds/icons@9.4.3

[pixelflips]

Something is still very wrong here. There should not be +231 −53 changes for a simple CSS adjustment. Please try rebasing against the develop branch.

[pixelflips]

Not seeing the correct gradient when a color property is not set.

[pixelflips]

I believe this is overwriting the default styles incorrectly. Please also check the component code and visually verify the examples on the doc site.

http://localhost:4000/pages/component/progress_bar?tab=preview

[pixelflips]

This approach would prevent #ff3e15 from being used as a custom color.

[pixelflips]

This approach still does not seem to allow for #ff3e15 to be used as a custom color.

For example, the following code still displays the gradient.

<%= sage_component SageProgressBar, {
  percent: 70,
  label: "Cloning product",
  color: "#ff3e15",
} %>

[pixelflips]

This should use the var(--pine-color-brand) token.

[pixelflips]

LGTM! Please do not merge until @QuintonJason approves as well.

[QuintonJason]

@cameronsimony @pixelflips Requesting changes because this fix feels too narrowly scoped. Since this introduces a gradient token into the system, we should take a system-wide approach to defining and using gradient components. The progress bar should consume this shared token rather than introducing a one-off implementation.

We’ll also need to build out the gradient options in the design files so we can explore and align on all possible variations before locking in an implementation.

Additionally, the current code does not allow for a custom gradient, which is a limitation we should address to maintain flexibility.

[QuintonJason]

please revert that last commit as discussion has not occurred