fix(styles): restore transition timing Tailwind was silently dropping

[waleedlatif1]

Summary

• tailwindcss-animate adds a duration-* utility for animation-duration, colliding with core's transition-duration — for arbitrary values Tailwind can't pick one, so it drops the class entirely and warns
• 52 usages across 13 files were producing no CSS at all, so they silently fell back to the defaults baked into Tailwind's transition-* utilities (150ms, cubic-bezier(0.4,0,0.2,1))
• Switched to the explicit [transition-duration:…] / [transition-timing-function:…] form, which is unambiguous
• Silences the 16 Tailwind warnings printed on every bun run dev:full

This is a visible change, not a no-op

Every affected element was animating — just at 150ms with the default curve instead of what the code asked for. Nothing snapped; things were simply too fast and eased wrong.

intended	actually ran at	ratio	usages
1700ms	150ms	11.3x too fast	2
850ms	150ms	5.7x	1
700ms	150ms	4.7x	1
620ms	150ms	4.1x	2
520ms	150ms	3.5x	2
450ms	150ms	3.0x	1
420ms	150ms	2.8x	3
380ms	150ms	2.5x	1
360ms	150ms	2.4x	3
220ms	150ms	1.5x	1
175ms	150ms	1.2x	1

All 31 ease-[cubic-bezier(…)] usages were also running on the default cubic-bezier(0.4,0,0.2,1) rather than their intended curve.

Expect the landing hero to visibly slow down — the two 1700ms transitions were running ~11x too fast. That is the intended design speed finally taking effect, but it is a real visual change and worth a look before merge.

Verification

Compiled the stylesheet on both sides:

transition-duration: 1700ms before=0 after=1
transition-duration: 420ms before=0 after=1
transition-duration: 175ms before=0 after=1
transition-timing-function: cubic-bezier(0.22,1,0.36,1) before=0 after=1
transition-timing-function: cubic-bezier(0.23,1,0.32,1) before=0 after=1
ambiguity warnings: 16 -> 0
stylesheet: 275,537 -> 276,962 bytes (+1,425 — exactly the missing rules)

Every usage sits in a transition context (transition-opacity, transition-transform, transition-[...]); none is alongside an animate-* utility, so transition-duration/transition-timing-function is the correct half of the collision in all 52 cases.

Type of Change

• Bug fix

Testing

Verified by compiling the stylesheet before and after and diffing the emitted rules (above). tsc --noEmit clean, bun run lint clean, landing tests pass. Not visually diffed in a browser — given this changes animation speed on the landing hero, that check is worth doing before merge.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Aug 1, 2026 6:44pm

[cursor]

PR Summary

Low Risk
CSS-only class renames with no runtime logic changes; risk is limited to visual animation timing regressions if a class were mistyped, which the PR author verified via compiled stylesheet diff.

Overview
Fixes a Tailwind utility collision with tailwindcss-animate: arbitrary duration-[…] and ease-[cubic-bezier(…)] on transition classes were dropped entirely (no duration or easing in CSS), so hero and workspace panels snapped instead of animating.

Across 13 files, those classes are replaced with explicit [transition-duration:…] and [transition-timing-function:…], leaving stock duration-200 / duration-300 where they were already unambiguous. No behavior or layout logic changes—only restored CSS for landing hero loops, enterprise graphics, workspace chrome slide timing, and Mothership pane width transitions.

^{Reviewed by Cursor Bugbot for commit 04c4d8e. Configure here.}