feat(colors): DLT-3354 split green palette into distinct light and dark mode values

[Joshua Hynes (hynes-dialpad)]

🛠️ Type Of Change

• Feature (with BREAKING CHANGE: footer — triggers MAJOR on release)

📖 Jira Ticket

DLT-3354

📖 Description

Rewrites color.green.* in base/default.json and base/dark.json as two independently authored palettes instead of one palette mirrored between modes.

• Light mode: teal-green hue family (H ≈ 155–169), maximum chroma at stop 500
• Dark mode: yellow-green hue family (H ≈ 125–135), brand green #9eeb4a-equivalent at stop 500

All 12 stops (50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 950, 1000) have new OKLCH values in both modes. The previous palette drifted hue across stops (mid stops leaned yellow-green, dark stops leaned teal) because the dark palette was a simple inversion of the light palette — the fix splits them into distinct hue families as approved by brand.

Downstream adjustments:

• theme/dp/{default,dark}.json — positive / positive-strong (and deprecated success / success-strong) semantic refs retuned to land on the intended stops in the new palette
• theme/dp/dark.json — action.color.background.positive.primary.hover retuned from {color.green.700} to {color.green.500}. Pre-split, dark.json was an inverted copy of light, so the old ref was darker than default. After the split, both palettes follow higher stop = lighter, which made hover brighten on dark mode. Now darkens (L 0.90 → 0.85), matching light-mode press-deeper feedback.
• components/badge/{default,dark}.json — background.success aligned with the existing Info/Warning sibling pattern (raw stop-200 refs). Light mode → {color.green.200}; dark mode override removed so it inherits and resolves to dark-palette green-200, landing badge in the same muted register as Info (dark navy) and Warning (dark brown).
• components/badge/default.json — new foreground.success entry ({color.green.1000}) so the badge label remains legible on the new background. APCA Lc 84.3 (dark) / 88.5 (light), passes Bronze body text.
• components/presence/dark.json — available retuned to {color.green.500}
• apps/dialtone-documentation/docs/.vuepress/theme/assets/less/dialtone-docs.less — .dialtone-usage component gains a --usage-item-color-foreground custom property so the &--do variant can override foreground alongside background, keeping do/don't badges legible on the refreshed success surface

💡 Context

The existing green palette was two systems fused together — the low and high ends of the scale leaned toward different hue regions, producing a muddy, inconsistent ramp (especially in dark mode). Users perceived the yellow-green as "brand" but only at specific stops; the teal tails looked off against brand. Splitting per mode lets each palette be internally coherent for its surface context: teal-green for light backgrounds, yellow-green for dark backgrounds.

Brand team approved the distinct-hue-per-mode approach. The starred brand green is preserved at dark-mode stop 500.

The follow-up commit (7a1afbd5f) addresses two regressions surfaced by visual review of the new palette: badge success backgrounds reading too saturated in dark mode (now muted-aligned with Info/Warning), and the positive button hover state brightening instead of darkening in dark mode (a structural regression — the old hover ref relied on the inverted-palette convention this PR replaces).

📦 Cross-Package Impact

Package	Changes	Downstream Impact
dialtone-tokens	Base palette + semantic + component token values retuned	CSS custom properties, Less variables, iOS Swift, Android XML/Kotlin, and doc-tokens JSON regenerate with new values
dialtone-documentation	.dialtone-usage Less tweak	Docs-site palette page auto-renders new swatches from the rebuilt tokens-docs.json; no manual page edit needed

Dependency flow: tokens → CSS → Vue → docs / MCP / language-server.

Consumers that reference --dt-color-green-* directly or via semantic tokens (--dt-color-foreground-positive, --dt-color-surface-success, etc.) will see visually shifted colors. No API changes; all token names and references are unchanged.

📄 Documentation Artifacts

Artifact	Status	Notes
Tokens source	✅ Updated	24 OKLCH values + semantic/component retunes + button-hover regression fix + badge bg alignment
CSS utilities	✅ Auto-regenerated	dialtone-css:build output reflects new values
Vue components	N/A	No component source changes
Component docs JSON	N/A	No new components
VuePress palette page	✅ Auto-regenerated	<ColorsCatalog> renders from tokens-docs.json; no manual edit
MCP server data	🚩 Deferred	Will land in follow-up chore commit

📝 Checklist

For all PRs:

• I have ensured no private Dialpad links or info are in the code or pull request description (Dialtone is a public repo!).
• I have reviewed my changes.
• I have added all relevant documentation.
• I have considered the performance impact of my change.

For all CSS changes:

• I have used design tokens whenever possible.
• I have considered how this change will behave on different screen sizes.
• I have visually validated my change in light and dark mode.
• I have used gap or flexbox properties for layout instead of margin whenever possible.

🔮 Next Steps

• Component token audit (follow-up): badge background.success (now {color.green.200} in light, inherited in dark) and foreground.success ({color.green.1000}), plus presence.color.available ({color.green.500}), are all raw palette refs. Per .claude/rules/design-tokens.md component tokens should reference semantic tokens. The current surface.{kind} family doesn't have stop-200-equivalent semantics for chip backgrounds — needs design input on whether to add one (e.g., surface.success-chip) or accept the existing info/warning raw-stop-200 pattern as established convention.
• Active-state asymmetry on positive button (dark): action.color.background.positive.primary.active references default instead of hover like light does, so dark-mode primary positive buttons have no visual feedback on press. Same regression class as the hover fix in this PR. Worth a follow-up commit/ticket.
• MCP server sync: update packages/dialtone-mcp-server/src/data.ts so search_tokens returns the new green values.
• Figma sync: pnpm --filter dialtone-tokens sync:tokens-to-figma deferred until the next branch merges; design team to run when ready.

📷 Screenshots / GIFs

Deploy preview will show the refreshed palette on /foundations/colors/palette/. The docs page auto-regenerates from the built tokens-docs.json.

🔗 Sources

• Jira: DLT-3354
• Related rule: .claude/rules/design-tokens.md (token hierarchy, OKLCH format, dark-mode override convention)

[coderabbitai]

Rewrites green color palette into independent light and dark OKLCH ramps (light: teal-green, dark: yellow-green) across all 12 stops, with coordinated retuning of downstream semantic, badge, presence, and theme tokens. Breaking change improving color coherence per-mode.

Overall Judgement: ✅ Ready to merge

Rationale: Comprehensive, intentional palette split with coordinated updates across dependent tokens and a clear breaking-change note.

Walkthrough

Updated green color ramp values and remapped success/positive token references across theme and component layers; added a badge success foreground token; adjusted presence “available” mapping; tweaked documentation usage header styling; added React dev dependencies to packages/dialtone-vue/package.json.

Changes

Cohort / File(s)	Summary
Documentation Styling apps/dialtone-documentation/docs/.vuepress/theme/assets/less/dialtone-docs.less	Changed .dialtone-usage header background token to --dt-color-surface-strong, introduced --usage-item-color-foreground (default --dt-color-foreground-primary-inverted) and wired heading color; &--do heading foreground overridden to --dt-color-foreground-success-strong-inverted.
Base Color Tokens packages/dialtone-tokens/tokens/base/default.json, packages/dialtone-tokens/tokens/base/dark.json	Replaced color.green ramp values (shades 50–1000) with new oklch(...) values in both default and dark base token files.
Component Tokens packages/dialtone-tokens/tokens/components/badge/default.json, packages/dialtone-tokens/tokens/components/presence/dark.json	Added badge.color.foreground.success referencing {color.green.1000}; updated presence.color.available in dark theme from {color.green.600} to {color.green.500}.
Theme Token Mappings packages/dialtone-tokens/tokens/theme/dp/default.json, packages/dialtone-tokens/tokens/theme/dp/dark.json	Remapped multiple success/positive/positive-strong foreground, surface, border, and inverted tokens to different color.green shade indices; adjusted inputs/positive action hover and presence/background mappings; one inverted brand border shade changed.
Package Metadata packages/dialtone-vue/package.json	Added dev dependencies @vitejs/plugin-react@6.0.1 and react-dom@19.2.4 alongside existing React tooling entries.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/DLT-3354-green-color-token-update

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a7881dc8b4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "Codex (@codex) review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "Codex (@codex) address that feedback".

[chatgpt-codex-connector]

Restore dark success badge contrast

When .d-badge--success is rendered in dark mode, the badge styles only swap the background token and keep text on --dt-badge-color-foreground-default (see packages/dialtone-css/lib/build/less/components/badge.less where lines 24 and 75-78 set this behavior). In dark tokens that foreground resolves to white ({color.black.1000}), so changing badge.color.background.success to {color.green.500} makes text/background contrast drop to about 1.48:1 from about 9.87:1 with the previous {color.green.200}, which makes success badges unreadable and fails accessibility contrast requirements.

Useful? React with 👍 / 👎.

[Francis Rupert (francisrupert)]

Real issue

[coderabbitai]

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/dialtone-tokens/tokens/components/badge/dark.json`:
- Around line 5-8: badge.color.background.success is referencing a base palette
token ("{color.green.500}") instead of a semantic component token; update the
value to point at the appropriate semantic background token (e.g., the project's
semantic color background success token) so the badge maps through semantic
tokens rather than a raw palette color—locate the badge.color.background.success
entry and replace the "{color.green.500}" reference with the corresponding
semantic token reference used across components (for example the project's
"{color.background.success}" or equivalent semantic token).

In `@packages/dialtone-tokens/tokens/components/badge/default.json`:
- Around line 14-15: The badge success color tokens in
tokens/components/badge/default.json currently reference base palette stops
(e.g. "{color.green.400}"); update these to reference the semantic success
aliases instead (e.g. replace "{color.green.400}" with the semantic token like
"{color.success.400}" or your repo's semantic success token) for both success
entries (the one shown and the other occurrence around lines 43-45) so component
tokens resolve through semantic color tokens rather than base green stops.

In `@packages/dialtone-tokens/tokens/components/presence/dark.json`:
- Line 5: The presence component token currently points directly at the base
palette value "{color.green.500}"; change it to reference the appropriate
semantic token (e.g. a presence/availability semantic like
"color.presence.available" or the project's success/availability semantic) so
the component uses a semantic token instead of the base palette; update the
token's "value" entry that currently equals "{color.green.500}" to the chosen
semantic token string so other themes/aliases resolve correctly.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited)

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 610910f3-48a3-4930-8606-497833117ef6

📥 Commits

Reviewing files that changed from the base of the PR and between c75201f and a7881dc.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (8)

• apps/dialtone-documentation/docs/.vuepress/theme/assets/less/dialtone-docs.less
• packages/dialtone-tokens/tokens/base/dark.json
• packages/dialtone-tokens/tokens/base/default.json
• packages/dialtone-tokens/tokens/components/badge/dark.json
• packages/dialtone-tokens/tokens/components/badge/default.json
• packages/dialtone-tokens/tokens/components/presence/dark.json
• packages/dialtone-tokens/tokens/theme/dp/dark.json
• packages/dialtone-tokens/tokens/theme/dp/default.json

[Francis Rupert (francisrupert)]

I won't get a chance to review more thoroughly today, but do make sure you look up any {color.green.*} reference in case you didn't catch them all.

I suspect you'll want to mainly be careful of dark since dp's default value often works for both light and dark, but then there are still plenty of cases where a dark override will definitely be needed – especially since base greens across light and dark vary far more than the other base colors.

[Francis Rupert (francisrupert)]

Honestly, I think these are good. I appreciate the greens in light mode better now, more teal-green, and dark mode's remaining as yellowish-green.

Let's go with this for now and keep an eye on it and tweak the references later if we need to.

I'm so used to covering the complete landscape of colors like this in Figma with Tokens Studio to ensure they're all consistent rather than jumping around.

The main thing that will need a bit of care is the -opaque ones as those are the main ones that are modified rather than a straight references to ensure they're render virtually identically on a primary surface (light and dark). I'll take a look at those soon.

Approving, as long as Badge is resolved with the comments below.

[Francis Rupert (francisrupert)]

For dark mode, I lean toward...

Suggested change

	"value": "{color.green.500}",
	"value": "{color.green.100}",

...or perhaps...

Suggested change

	"value": "{color.green.500}",
	"value": "{color.green.200}",

[Francis Rupert (francisrupert)]

400 doesn't look balanced with others in light mode. I lean toward...

Suggested change

	"value": "{color.green.400}",
	"value": "{color.green.300}",

[github-actions]

Please add either the visual-test-ready or no-visual-test label to this PR depending on whether you want to run visual tests or not.
It is recommended to run visual tests if your PR changes any UI. ‼️

[coderabbitai]

♻️ Duplicate comments (1)

packages/dialtone-tokens/tokens/components/badge/default.json (1)

43-45: ⚠️ Potential issue | 🟠 Major

Route badge success foreground through a semantic token.

{color.green.1000} bypasses the semantic layer. Please point this badge token at the matching semantic positive token instead so it stays aligned with theme retunes and future palette changes.

Proposed fix

-          "value": "{color.green.1000}",
+          "value": "{color.foreground.positive-strong}",

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/dialtone-tokens/tokens/components/badge/default.json` around lines
43 - 45, The "success" badge token currently points directly at a raw green
value ("{color.green.1000}") which bypasses the semantic layer; update the
"success" token's value to reference the project’s semantic positive/success
foreground token (replace the "{color.green.1000}" value for the "success" key
in tokens/components/badge/default.json with the matching semantic token name
used elsewhere, e.g. the semantic positive/success foreground token like
"{color.positive.foreground}" or the repo's equivalent) so the badge follows
theme retunes and palette changes.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@packages/dialtone-tokens/tokens/components/badge/default.json`:
- Around line 43-45: The "success" badge token currently points directly at a
raw green value ("{color.green.1000}") which bypasses the semantic layer; update
the "success" token's value to reference the project’s semantic positive/success
foreground token (replace the "{color.green.1000}" value for the "success" key
in tokens/components/badge/default.json with the matching semantic token name
used elsewhere, e.g. the semantic positive/success foreground token like
"{color.positive.foreground}" or the repo's equivalent) so the badge follows
theme retunes and palette changes.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited)

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 52b1529f-a3dd-4a3a-a475-30be81ad2155

📥 Commits

Reviewing files that changed from the base of the PR and between a7881dc and 7a1afbd.

📒 Files selected for processing (2)

• packages/dialtone-tokens/tokens/components/badge/default.json
• packages/dialtone-tokens/tokens/theme/dp/dark.json

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/dialtone-vue/package.json`:
- Around line 68-72: The package.json currently lists "@vitejs/plugin-react":
"6.0.1" which requires Node ^20.19.0 || >=22.12.0 while engines.node is ">=
14.17"; either update the engines.node field to a minimum that satisfies the
plugin (e.g., ">= 20.19.0") or pin `@vitejs/plugin-react` to a
Node-14/16/18-compatible release (downgrade the dependency to a 5.x version),
then run npm install/lockfile update and verify CI to ensure consistency; touch
the "engines.node" key or the dependency line for "@vitejs/plugin-react" in
package.json accordingly.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited)

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: ca0c0778-9b3a-4e5f-87a1-fd4573ed1752

📥 Commits

Reviewing files that changed from the base of the PR and between 7a1afbd and e85e951.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (1)

• packages/dialtone-vue/package.json

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

python - <<'PY'
import json
import subprocess

pkg_path = "packages/dialtone-vue/package.json"
with open(pkg_path, "r", encoding="utf-8") as f:
    pkg = json.load(f)

declared = pkg.get("engines", {}).get("node")
print(f"Declared engines.node ({pkg_path}): {declared}")

checks = [
    ("@vitejs/plugin-react", "6.0.1"),
    ("react-dom", "19.2.4"),
    ("@storybook/vue3-vite", "10.3.0"),
]

for name, version in checks:
    try:
        out = subprocess.check_output(
            ["npm", "view", f"{name}@{version}", "engines", "--json"],
            text=True
        ).strip() or "null"
        print(f"{name}@{version} -> engines: {out}")
    except subprocess.CalledProcessError as e:
        print(f"{name}@{version} -> lookup failed: {e}")
PY

Repository: dialpad/dialtone

Length of output: 777

---

Fix Node engine compatibility before merge.

@vitejs/plugin-react@6.0.1 (line 68) requires Node ^20.19.0 || >=22.12.0, but the package declares engines.node: >= 14.17. This breaks all consumers on Node 14.17–20.18.x. Either bump engines.node to reflect the new floor or pin a compatible @vitejs/plugin-react version.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/dialtone-vue/package.json` around lines 68 - 72, The package.json
currently lists "@vitejs/plugin-react": "6.0.1" which requires Node ^20.19.0 ||
>=22.12.0 while engines.node is ">= 14.17"; either update the engines.node field
to a minimum that satisfies the plugin (e.g., ">= 20.19.0") or pin
`@vitejs/plugin-react` to a Node-14/16/18-compatible release (downgrade the
dependency to a 5.x version), then run npm install/lockfile update and verify CI
to ensure consistency; touch the "engines.node" key or the dependency line for
"@vitejs/plugin-react" in package.json accordingly.

[github-actions]

✔️ Deploy previews ready!
😎 Dialtone documentation preview: https://dialtone.dialpad.com/deploy-previews/pr-1225/
😎 Dialtone-vue preview: https://dialtone.dialpad.com/vue/deploy-previews/pr-1225/