feat: line-spanning foreground gradients via overrideForegroundColor

[cameronsjo]

What

Adds foreground gradients to ccstatusline at two scopes, on one shared OKLab engine:

• Line-spanning — overrideForegroundColor: "gradient:…" paints the whole status line with one continuous sweep; each visible character is colored by its column across the line.
• Per-widget — widget.color: "gradient:…" gives a single widget its own self-contained sweep, alongside the existing solid colors. Configurable in the TUI (g in the color menu).

// whole line:
"overrideForegroundColor": "gradient:hex:dbbb6f,hex:c4808a,hex:9070d0,hex:b8cad4,hex:4a8a5e"
// one widget:
{ "type": "model", "color": "gradient:atlas" }

Three spec forms: a named preset (gradient:atlas, gradient:rainbow, …), dash stops (gradient:RRGGBB-RRGGBB), or comma stops (gradient:hex:…,#…,…). Two or more stops.

Why one core

This converges two same-day PRs. #404 by @akkaz (opened first) added gradient as a per-widget color with named presets (reproduced from gradient-string, MIT) and a ColorMenu picker; this PR added the line-spanning form. Both create src/utils/gradient.ts, so they'd conflict. Rather than compete, they're meshed onto a single engine that offers both scopes.

Colors interpolate in OKLab for perceptually even blends — no muddy mid-tones, no tinygradient/HSV dependency. rainbow/pastel (originally HSV hue-spins) are re-expressed as explicit multi-stop hue wheels so OKLab reproduces them. Zero new dependencies.

How

• gradient.ts — parseGradientSpec (presets + dash + comma → Rgb[]), OKLab sampleGradient, rgbToAnsi256, gradientCodeAt, applyGradientToText (per-widget), plus GRADIENT_PRESETS.
• colors.ts — per-widget gradient in applyColors; getColorAnsiCode collapses a gradient to its first stop as a solid (what the powerline renderer and the ansi16 path see).
• ansi.ts — applyLineGradient reuses the existing parseEscapeSequence / consumeDisplayCluster walkers, so OSC-8 hyperlinks pass through and visible width is unchanged (flexMode unaffected).
• renderer.ts — line-span pass after assembly, before truncation; suppresses a widget's solid fg when a line-span gradient owns the line.
• ColorMenu.tsx — g opens a gradient picker (preset list + custom hex), foreground-only, colorLevel ≥ 2.

Precedence: line-span override > per-widget color: gradient: > solid.

Color levels & scope

• truecolor → 38;2;r;g;b; ansi256 → nearest 6×6×6 / grayscale; ansi16 → per-widget degrades to a solid first stop, line-span is a no-op.
• Gradients self-degrade at render time, so color-sanitize leaves them untouched at every level.
• Powerline: separators derive fg from bg, so a line-span gradient is not applied there; per-widget gradients degrade to their first-stop solid. (Full powerline support is a follow-up.)

Tests

bun test green (1426 pass). Covers preset/dash/comma parsing, OKLab sampling, ansi256 mapping, per-widget applyGradientToText (whitespace-skipped, restart-per-call), line-span width-invariance, OSC-8 passthrough, the per-widget applyColors path at all levels, first-stop fallback, and the self-degrade-across-levels sanitize behavior. bun run lint + bun tsc --noEmit clean.

Credit

Per-widget gradients, the preset list, and the TUI picker come from #404 by @akkaz — this PR carries that design forward on the shared OKLab core. 🙏

Follow-ups (not in this PR)

• TUI authoring for the line-span overrideForegroundColor gradient
• Powerline support (gradient over text glyphs only, skipping separators)
• Per-line scoping; direction/reverse modifier

🤖 Generated with Claude Code

[akkaz]

Nice work converging both scopes onto a single dependency-free OKLab core — the line-span + per-widget split reads really cleanly. 👏

Replied on #404 re: how we land the attribution. tl;dr: I'd love to stay a real contributor on the merged history — ideally by preserving my original #404 commit, or at minimum a Co-authored-by: akkaz <giomarco@cleversoft.it> trailer on the per-widget commit. Other than that I'm happy to converge here and review. 🙌

[cameronsjo]

Thanks for the steer, @sirmalloc. Just force-pushed: the per-widget mesh commit (98f384f) now carries Co-authored-by: akkaz <giomarco@cleversoft.it>, so the squash should credit us both on the Contributors graph. Ready for review when you have a moment.

[akkaz]

Heads up on a possible follow-up. I have rebuilt the value-driven dynamic color feature from my fork on top of this gradient engine. Instead of a separate dynamic: color prefix, it is now an orthogonal per-widget toggle: when enabled, a widget picks its color by its current fill ratio. If the widget color is a gradient it samples those stops directly; if it is a solid color it derives an in-hue intensity ramp in OKLab: a pale, light tint at low fill through to a deep, saturated shade at high fill, holding the hue constant. So an orange widget runs from light orange to deep orange, a blue one from light blue to deep blue, and so on.

It covers the context, session and weekly usage bars plus the reset timers, with a (d)ynamic toggle in the color menu and an automatic settings migration for existing configs. I kept it separate rather than folding it in here so this PR stays focused on the gradient core. Happy to open it as a follow-up once this lands.