+```
+
+## CSS Transform Mastery
+
+### translateY with percentages
+
+Percentage values in `translate()` are relative to the element's own size. Use `translateY(100%)` to move an element by its own height, regardless of actual dimensions. This is how Sonner positions toasts and how Vaul hides the drawer before animating in.
+
+```css
+/* Works regardless of drawer height */
+.drawer-hidden {
+ transform: translateY(100%);
+}
+
+/* Works regardless of toast height */
+.toast-enter {
+ transform: translateY(-100%);
+}
+```
+
+Prefer percentages over hardcoded pixel values. They are less error-prone and adapt to content.
+
+### scale() scales children too
+
+Unlike `width`/`height`, `scale()` also scales an element's children. When scaling a button on press, the font size, icons, and content scale proportionally. This is a feature, not a bug.
+
+### 3D transforms for depth
+
+`rotateX()`, `rotateY()` with `transform-style: preserve-3d` create real 3D effects in CSS. Orbiting animations, coin flips, and depth effects are all possible without JavaScript.
+
+```css
+.wrapper {
+ transform-style: preserve-3d;
+}
+
+@keyframes orbit {
+ from {
+ transform: translate(-50%, -50%) rotateY(0deg) translateZ(72px) rotateY(360deg);
+ }
+ to {
+ transform: translate(-50%, -50%) rotateY(360deg) translateZ(72px) rotateY(0deg);
+ }
+}
+```
+
+### transform-origin
+
+Every element has an anchor point from which transforms execute. The default is center. Set it to match where the trigger lives for origin-aware interactions.
+
+## clip-path for Animation
+
+`clip-path` is not just for shapes. It is one of the most powerful animation tools in CSS.
+
+### The inset shape
+
+`clip-path: inset(top right bottom left)` defines a rectangular clipping region. Each value "eats" into the element from that side.
+
+```css
+/* Fully hidden from right */
+.hidden {
+ clip-path: inset(0 100% 0 0);
+}
+
+/* Fully visible */
+.visible {
+ clip-path: inset(0 0 0 0);
+}
+
+/* Reveal from left to right */
+.overlay {
+ clip-path: inset(0 100% 0 0);
+ transition: clip-path 200ms ease-out;
+}
+.button:active .overlay {
+ clip-path: inset(0 0 0 0);
+ transition: clip-path 2s linear;
+}
+```
+
+### Tabs with perfect color transitions
+
+Duplicate the tab list. Style the copy as "active" (different background, different text color). Clip the copy so only the active tab is visible. Animate the clip on tab change. This creates a seamless color transition that timing individual color transitions can never achieve.
+
+### Hold-to-delete pattern
+
+Use `clip-path: inset(0 100% 0 0)` on a colored overlay. On `:active`, transition to `inset(0 0 0 0)` over 2s with linear timing. On release, snap back with 200ms ease-out. Add `scale(0.97)` on the button for press feedback.
+
+### Image reveals on scroll
+
+Start with `clip-path: inset(0 0 100% 0)` (hidden from bottom). Animate to `inset(0 0 0 0)` when the element enters the viewport. Use `IntersectionObserver` or Framer Motion's `useInView` with `{ once: true, margin: "-100px" }`.
+
+### Comparison sliders
+
+Overlay two images. Clip the top one with `clip-path: inset(0 50% 0 0)`. Adjust the right inset value based on drag position. No extra DOM elements needed, fully hardware-accelerated.
+
+## Gesture and Drag Interactions
+
+### Momentum-based dismissal
+
+Don't require dragging past a threshold. Calculate velocity: `Math.abs(dragDistance) / elapsedTime`. If velocity exceeds ~0.11, dismiss regardless of distance. A quick flick should be enough.
+
+```js
+const timeTaken = new Date().getTime() - dragStartTime.current.getTime();
+const velocity = Math.abs(swipeAmount) / timeTaken;
+
+if (Math.abs(swipeAmount) >= SWIPE_THRESHOLD || velocity > 0.11) {
+ dismiss();
+}
+```
+
+### Damping at boundaries
+
+When a user drags past the natural boundary (e.g., dragging a drawer up when already at top), apply damping. The more they drag, the less the element moves. Things in real life don't suddenly stop; they slow down first.
+
+### Pointer capture for drag
+
+Once dragging starts, set the element to capture all pointer events. This ensures dragging continues even if the pointer leaves the element bounds.
+
+### Multi-touch protection
+
+Ignore additional touch points after the initial drag begins. Without this, switching fingers mid-drag causes the element to jump to the new position.
+
+```js
+function onPress() {
+ if (isDragging) return;
+ // Start drag...
+}
+```
+
+### Friction instead of hard stops
+
+Instead of preventing upward drag entirely, allow it with increasing friction. It feels more natural than hitting an invisible wall.
+
+## Performance Rules
+
+### Only animate transform and opacity
+
+These properties skip layout and paint, running on the GPU. Animating `padding`, `margin`, `height`, or `width` triggers all three rendering steps.
+
+### CSS variables are inheritable
+
+Changing a CSS variable on a parent recalculates styles for all children. In a drawer with many items, updating `--swipe-amount` on the container causes expensive style recalculation. Update `transform` directly on the element instead.
+
+```js
+// Bad: triggers recalc on all children
+element.style.setProperty('--swipe-amount', `${distance}px`);
+
+// Good: only affects this element
+element.style.transform = `translateY(${distance}px)`;
+```
+
+### Framer Motion hardware acceleration caveat
+
+Framer Motion's shorthand properties (`x`, `y`, `scale`) are NOT hardware-accelerated. They use `requestAnimationFrame` on the main thread. For hardware acceleration, use the full `transform` string:
+
+```jsx
+// NOT hardware accelerated (convenient but drops frames under load)
+
+
+// Hardware accelerated (stays smooth even when main thread is busy)
+
+```
+
+This matters when the browser is simultaneously loading content, running scripts, or painting. At Vercel, the dashboard tab animation used Shared Layout Animations and dropped frames during page loads. Switching to CSS animations (off main thread) fixed it.
+
+### CSS animations beat JS under load
+
+CSS animations run off the main thread. When the browser is busy loading a new page, Framer Motion animations (using `requestAnimationFrame`) drop frames. CSS animations remain smooth. Use CSS for predetermined animations; JS for dynamic, interruptible ones.
+
+### Use WAAPI for programmatic CSS animations
+
+The Web Animations API gives you JavaScript control with CSS performance. Hardware-accelerated, interruptible, and no library needed.
+
+```js
+element.animate([{ clipPath: 'inset(0 0 100% 0)' }, { clipPath: 'inset(0 0 0 0)' }], {
+ duration: 1000,
+ fill: 'forwards',
+ easing: 'cubic-bezier(0.77, 0, 0.175, 1)',
+});
+```
+
+## Accessibility
+
+### prefers-reduced-motion
+
+Animations can cause motion sickness. Reduced motion means fewer and gentler animations, not zero. Keep opacity and color transitions that aid comprehension. Remove movement and position animations.
+
+```css
+@media (prefers-reduced-motion: reduce) {
+ .element {
+ animation: fade 0.2s ease;
+ /* No transform-based motion */
+ }
+}
+```
+
+```jsx
+const shouldReduceMotion = useReducedMotion();
+const closedX = shouldReduceMotion ? 0 : '-100%';
+```
+
+### Touch device hover states
+
+```css
+@media (hover: hover) and (pointer: fine) {
+ .element:hover {
+ transform: scale(1.05);
+ }
+}
+```
+
+Touch devices trigger hover on tap, causing false positives. Gate hover animations behind this media query.
+
+## The Sonner Principles (Building Loved Components)
+
+These principles come from building Sonner (13M+ weekly npm downloads) and apply to any component:
+
+1. **Developer experience is key.** No hooks, no context, no complex setup. Insert `
` once, call `toast()` from anywhere. The less friction to adopt, the more people will use it.
+
+2. **Good defaults matter more than options.** Ship beautiful out of the box. Most users never customize. The default easing, timing, and visual design should be excellent.
+
+3. **Naming creates identity.** "Sonner" (French for "to ring") feels more elegant than "react-toast". Sacrifice discoverability for memorability when appropriate.
+
+4. **Handle edge cases invisibly.** Pause toast timers when the tab is hidden. Fill gaps between stacked toasts with pseudo-elements to maintain hover state. Capture pointer events during drag. Users never notice these, and that is exactly right.
+
+5. **Use transitions, not keyframes, for dynamic UI.** Toasts are added rapidly. Keyframes restart from zero on interruption. Transitions retarget smoothly.
+
+6. **Build a great documentation site.** Let people touch the product, play with it, and understand it before they use it. Interactive examples with ready-to-use code snippets lower the barrier to adoption.
+
+### Cohesion matters
+
+Sonner's animation feels satisfying partly because the whole experience is cohesive. The easing and duration fit the vibe of the library. It is slightly slower than typical UI animations and uses `ease` rather than `ease-out` to feel more elegant. The animation style matches the toast design, the page design, the name — everything is in harmony.
+
+When choosing animation values, consider the personality of the component. A playful component can be bouncier. A professional dashboard should be crisp and fast. Match the motion to the mood.
+
+### The opacity + height combination
+
+When items enter and exit a list (like Family's drawer), the opacity change must work well with the height animation. This is often trial and error. There is no formula — you adjust until it feels right.
+
+### Review your work the next day
+
+Review animations with fresh eyes. You notice imperfections the next day that you missed during development. Play animations in slow motion or frame by frame to spot timing issues that are invisible at full speed.
+
+### Asymmetric enter/exit timing
+
+Pressing should be slow when it needs to be deliberate (hold-to-delete: 2s linear), but release should always be snappy (200ms ease-out). This pattern applies broadly: slow where the user is deciding, fast where the system is responding.
+
+```css
+/* Release: fast */
+.overlay {
+ transition: clip-path 200ms ease-out;
+}
+
+/* Press: slow and deliberate */
+.button:active .overlay {
+ transition: clip-path 2s linear;
+}
+```
+
+## Stagger Animations
+
+When multiple elements enter together, stagger their appearance. Each element animates in with a small delay after the previous one. This creates a cascading effect that feels more natural than everything appearing at once.
+
+```css
+.item {
+ opacity: 0;
+ transform: translateY(8px);
+ animation: fadeIn 300ms ease-out forwards;
+}
+
+.item:nth-child(1) {
+ animation-delay: 0ms;
+}
+.item:nth-child(2) {
+ animation-delay: 50ms;
+}
+.item:nth-child(3) {
+ animation-delay: 100ms;
+}
+.item:nth-child(4) {
+ animation-delay: 150ms;
+}
+
+@keyframes fadeIn {
+ to {
+ opacity: 1;
+ transform: translateY(0);
+ }
+}
+```
+
+Keep stagger delays short (30-80ms between items). Long delays make the interface feel slow. Stagger is decorative — never block interaction while stagger animations are playing.
+
+## Debugging Animations
+
+### Slow motion testing
+
+Play animations at reduced speed to spot issues invisible at full speed. Temporarily increase duration to 2-5x normal, or use browser DevTools animation inspector to slow playback.
+
+Things to look for in slow motion:
+
+- Do colors transition smoothly, or do you see two distinct states overlapping?
+- Does the easing feel right, or does it start/stop abruptly?
+- Is the transform-origin correct, or does the element scale from the wrong point?
+- Are multiple animated properties (opacity, transform, color) in sync?
+
+### Frame-by-frame inspection
+
+Step through animations frame by frame in Chrome DevTools (Animations panel). This reveals timing issues between coordinated properties that you cannot see at full speed.
+
+### Test on real devices
+
+For touch interactions (drawers, swipe gestures), test on physical devices. Connect your phone via USB, visit your local dev server by IP address, and use Safari's remote devtools. The Xcode Simulator is an alternative but real hardware is better for gesture testing.
+
+## Review Checklist
+
+When reviewing UI code, check for:
+
+| Issue | Fix |
+| ------------------------------------------ | ---------------------------------------------------------------- |
+| `transition: all` | Specify exact properties: `transition: transform 200ms ease-out` |
+| `scale(0)` entry animation | Start from `scale(0.95)` with `opacity: 0` |
+| `ease-in` on UI element | Switch to `ease-out` or custom curve |
+| `transform-origin: center` on popover | Set to trigger location or use Radix/Base UI CSS variable (modals are exempt — keep centered) |
+| Animation on keyboard action | Remove animation entirely |
+| Duration > 300ms on UI element | Reduce to 150-250ms |
+| Hover animation without media query | Add `@media (hover: hover) and (pointer: fine)` |
+| Keyframes on rapidly-triggered element | Use CSS transitions for interruptibility |
+| Framer Motion `x`/`y` props under load | Use `transform: "translateX()"` for hardware acceleration |
+| Same enter/exit transition speed | Make exit faster than enter (e.g., enter 2s, exit 200ms) |
+| Elements all appear at once | Add stagger delay (30-80ms between items) |
diff --git a/.cursor/skills/frontend-design/SKILL.md b/.cursor/skills/frontend-design/SKILL.md
new file mode 100755
index 000000000..8feb88e5d
--- /dev/null
+++ b/.cursor/skills/frontend-design/SKILL.md
@@ -0,0 +1,114 @@
+---
+name: frontend-design
+description: Build distinctive, production-quality UI. Use when creating or reshaping user-facing interfaces, components, pages, layouts, visual redesigns, responsive behavior, loading/error/empty states, or accessibility-sensitive frontend work.
+---
+
+# Frontend Design & UI Quality
+
+Approach this as the design lead at a small studio known for giving every client a visual identity that could not be mistaken for anyone else's. Make deliberate, opinionated choices about palette, typography, layout, motion, and copy that are specific to the brief, then execute them with engineering rigor: accessible, responsive, performant, and complete in every state.
+
+## 1. Aesthetic Direction
+
+### Ground It In The Subject
+
+If the brief does not pin down the product or subject, pin it yourself before designing: name one concrete subject, its audience, and the page's single job. Use the user's preferences, project context, and previous design choices as hints. The subject's world - its materials, instruments, artifacts, and vernacular - is where distinctive choices come from. Build with real or realistic content throughout. Never use lorem ipsum; placeholder text hides wrapping, overflow, hierarchy, and tone problems.
+
+### Design Principles
+
+For web designs, the hero is a thesis. Open with the most characteristic thing in the subject's world: a headline, image, animation, live demo, interactive moment, or concrete product artifact. A big number with a small label, supporting stats, and a gradient accent is the template answer; only use it if it is truly the best option.
+
+Typography carries personality. Pair display and body faces deliberately, not the same families you would reach for on every project. Set a clear type scale with intentional weights, widths, spacing, and rhythm. Respect semantic hierarchy: one `h1` per page, no skipped heading levels, and no heading styles on non-heading content.
+
+Structure is information. Numbering, eyebrows, dividers, labels, cards, and section breaks should encode something true about the content, not decorate it. Numbered markers like `01 / 02 / 03` only belong when the content is actually sequential.
+
+Leverage motion deliberately. One orchestrated moment usually lands harder than scattered effects. Always respect `prefers-reduced-motion`.
+
+Match complexity to the vision. Maximalist directions need elaborate execution; minimal directions need precision in spacing, type, and detail. Elegance is executing the chosen vision well.
+
+### Known AI Defaults
+
+Avoid defaulting to: warm cream + high-contrast serif + terracotta; near-black + acid green/vermilion; broadsheet layouts with hairline rules; purple/indigo everything; decorative gradients; `rounded-2xl` everywhere; generic hero sections; uniform card grids that ignore information priority; oversized equal padding; layered shadows. These can be valid when the brief calls for them, but they must be choices, not reflexes.
+
+### Existing Product Rule
+
+If the project already has a design system, tokens, components, palette, radius scale, or layout language, that system is the brief. Distinctiveness then lives in hierarchy, composition, content, interaction, and motion - not in inventing stray colors or one-off radii. Use semantic tokens, existing components, and the established spacing scale. Avoid raw hex values or off-scale spacing unless the design system itself requires them.
+
+## 2. Process
+
+Work in two passes.
+
+First, create a compact design plan:
+
+- **Color:** 4-6 named hex values for greenfield work, or the exact tokens to use in an existing product.
+- **Type:** roles for display, body, and utility/caption text.
+- **Layout:** one-sentence concept plus quick ASCII wireframes when useful.
+- **Signature:** the single element this interface should be remembered by.
+
+Second, critique the plan against the brief before building. If any part could appear unchanged in a generic page for a different subject, revise it. Only then write code. Derive every visual choice from the revised plan or the existing design system.
+
+When writing CSS, watch selector specificity. Generated class names often cancel each other out around section spacing, component padding, and element selectors. Prefer simple, local class structure and design-system utilities over clever selector chains.
+
+## 3. Engineering The Design
+
+### Components
+
+- Prefer composition over configuration: structured children over prop grab-bags.
+- Keep components focused; split anything past roughly 200 lines unless there is a strong local reason not to.
+- Separate data fetching from presentation. Containers resolve loading/error/empty and pass clean data to presentational components.
+- Choose the simplest state that works: `useState` for component UI state; lifted state for 2-3 siblings; context for read-heavy/write-rare concerns like theme, auth, locale; URL state for shareable filters/pagination; SWR/React Query for server data; global stores only for genuinely app-wide client state.
+- Avoid prop drilling past 3 levels. Restructure or introduce context when intermediate components do not use the props.
+
+### Four UI States
+
+Design loading, error, empty, and success together.
+
+- **Loading:** use skeletons that match content shape for content areas. Add `aria-busy="true"` where appropriate.
+- **Error:** say what went wrong and how to fix it. Offer retry when retrying can work.
+- **Empty:** treat it as an invitation to act: icon or marker, short explanation, and a primary action. Never leave a blank region. Use `role="status"` when the empty state announces a result.
+- **Success:** optimize the default path without hiding constraints, secondary actions, or overflow cases.
+
+Use optimistic updates for quick mutations where rollback is cheap and failure is understandable.
+
+### Accessibility
+
+Meet WCAG 2.1 AA as a floor.
+
+- Use native elements first: `button`, `a`, `label`, `input`, `select`, `textarea`, `dialog`.
+- A clickable `div` needs `role`, `tabIndex`, and keyboard handling for Enter/Space; prefer a real `button`.
+- Every icon-only control needs an `aria-label`. Every input needs a visible label or explicit accessible name.
+- Focus must be visible. Dialogs and popovers move focus on open and restore it on close; modal dialogs trap focus.
+- Contrast: 4.5:1 for normal text, 3:1 for large text and non-text UI indicators.
+- Do not use color as the only state indicator. Pair color with text, iconography, shape, or pattern.
+- Respect `prefers-reduced-motion` for animation and transitions.
+
+### Responsive
+
+Design mobile-first, then expand. Verify at 320px, 768px, 1024px, and 1440px. Check text wrapping, overflow, touch targets, sticky elements, modals, tables, and long localized strings, not just whether the layout stacks.
+
+## 4. Restraint And Self-Critique
+
+Spend boldness in one place. Let the signature element be the memorable move; keep everything around it quiet and disciplined. Cut decoration that does not serve the brief. Not taking a risk can also be a risk.
+
+Critique the work visually as you build. If screenshots are available, use them. Before presenting, remove one accessory: one extra border, glow, gradient, icon, animation, card, or label that weakens the hierarchy.
+
+## 5. Writing In The Design
+
+Words make the interface easier to understand and use. They are design material, not decoration.
+
+Write from the end user's side of the screen. Name things by what people control and recognize, not by internal implementation. A person manages notifications, not webhook config. Be specific rather than clever.
+
+Use active voice. A control says exactly what happens: "Save changes," not "Submit." Keep action vocabulary consistent through the whole flow: "Publish" leads to "Published."
+
+Treat failure and emptiness as moments for direction, not mood. Errors do not apologize and are never vague. Empty states invite the next action.
+
+Keep copy conversational and tuned: plain verbs, sentence case, no filler, with tone matched to the brand and audience. Each element does one job: a label labels, an example demonstrates, helper text helps.
+
+## Verification Checklist
+
+Before presenting UI work, verify:
+
+- [ ] Design direction is specific to the brief, not a generic default.
+- [ ] Existing design-system tokens, spacing, components, and typography are respected.
+- [ ] Realistic content, loading, error, empty, and success states are handled.
+- [ ] Keyboard navigation, focus, labels, contrast, and reduced motion are covered.
+- [ ] Layout works at 320px, 768px, 1024px, and 1440px with no obvious overflow.
diff --git a/.cursor/skills/review-animations/SKILL.md b/.cursor/skills/review-animations/SKILL.md
new file mode 100644
index 000000000..6b46fd332
--- /dev/null
+++ b/.cursor/skills/review-animations/SKILL.md
@@ -0,0 +1,112 @@
+---
+name: review-animations
+description: Reviews animation and motion code against a high craft bar derived from Emil Kowalski's design engineering philosophy. Default to flagging; approval is earned.
+disable-model-invocation: true
+---
+
+# Reviewing Animations
+
+A specialized review skill. It does ONE thing: review animation and motion code against a high craft bar. It does not write features, fix unrelated bugs, or review non-motion code. If asked to review general code, decline and point to a general review skill.
+
+## Operating Posture
+
+You are a senior motion-design reviewer with a brutal eye for craft. Your bias is toward **motion that feels right**, not motion that merely runs. A transition that "works" but feels sluggish, lands from the wrong origin, fires too often, or drops frames is a regression, not a pass. Default to flagging. Approval is earned, not assumed.
+
+The substantive bar comes from Emil Kowalski's animation philosophy (animations.dev). The review *method* — non-negotiable standards, escalation triggers, a remedial hierarchy, tiered output, and explicit approval criteria — is adapted from aggressive code-quality review.
+
+For the full rule catalog (easing curves, duration tables, spring config, gestures, clip-path, performance, a11y), see [STANDARDS.md](STANDARDS.md). Load it whenever a finding needs a precise value or citation.
+
+## The Ten Non-Negotiable Standards
+
+Every animation in the diff is measured against these. A violation is a finding.
+
+1. **Justified motion.** Every animation must answer "why does this animate?" — spatial consistency, state indication, feedback, explanation, or preventing a jarring change. "It looks cool" on a frequently-seen element is a block.
+
+2. **Frequency-appropriate.** Match motion to how often it's seen. Keyboard-initiated and 100+/day actions get **no** animation. Tens/day gets reduced motion. Occasional gets standard. Rare/first-time can have delight.
+
+3. **Responsive easing.** Entering/exiting elements use `ease-out` or a strong custom curve. `ease-in` on UI is a block — it delays the moment the user watches most. Built-in CSS easings are too weak; expect custom cubic-beziers.
+
+4. **Sub-300ms UI.** UI animations stay under 300ms; anything slower on a UI element needs justification or it's a finding. Per-element budgets live in [STANDARDS.md](STANDARDS.md).
+
+5. **Origin & physical correctness.** Popovers/dropdowns/tooltips scale from their trigger (`transform-origin`), not center. Never animate from `scale(0)` — start from `scale(0.9–0.97)` + opacity (Modals are exempt — they stay centered.)
+
+6. **Interruptibility.** Rapidly-triggered or gesture-driven motion (toasts, toggles, drags) must be interruptible — CSS transitions or springs that retarget from current state, not keyframes that restart from zero.
+
+7. **GPU-only properties.** Animate `transform` and `opacity` only. Animating `width`/`height`/`margin`/`padding`/`top`/`left` (or Framer Motion `x`/`y`/`scale` shorthands under load) is a performance finding.
+
+8. **Accessibility.** `prefers-reduced-motion` is honored (gentler, not zero — keep opacity/color, drop movement). Hover animations are gated behind `@media (hover: hover) and (pointer: fine)`.
+
+9. **Asymmetric enter/exit.** Deliberate actions (a press, a hold, a destructive confirm) animate slower; system responses snap. Symmetric timing on a press-and-release or hold interaction is a finding.
+
+10. **Cohesion.** Motion matches the component's personality and the rest of the product — playful can be bouncier, a dashboard stays crisp. Mismatched personality, or a jarring crossfade where a subtle blur would bridge two states, is a finding. When unsure whether motion feels right, the strongest move is often to delete it.
+
+## Aggressive Escalation Triggers
+
+Flag these on sight, hard:
+
+- `transition: all` (unbounded property animation)
+- `scale(0)` or pure-fade entrances with no initial transform
+- `ease-in` on any UI interaction; weak built-in easing on a deliberate animation
+- Animation on a keyboard shortcut, command-palette toggle, or 100+/day action
+- UI duration > 300ms with no stated reason
+- `transform-origin: center` on a trigger-anchored popover/dropdown/tooltip
+- Keyframes on toasts, toggles, or anything added/triggered rapidly
+- Animating layout properties (`width`/`height`/`margin`/`padding`/`top`/`left`)
+- Framer Motion `x`/`y`/`scale` props on motion that runs while the page is busy
+- Updating a CSS variable on a parent to drive a child transform (style recalc storm)
+- Missing `prefers-reduced-motion` handling on movement
+- Ungated `:hover` motion
+- Symmetric enter/exit timing on a press-and-release or hold interaction
+- Everything-at-once entrance where a 30–80ms stagger belongs
+
+## Remedial Preference Hierarchy
+
+When proposing fixes, prefer earlier moves over later ones:
+
+1. **Delete the animation** (high-frequency / no purpose / keyboard-triggered).
+2. **Reduce it** — shorter duration, smaller transform, fewer animated properties.
+3. **Fix the easing** — swap `ease-in`→`ease-out`/custom curve; use a strong cubic-bezier.
+4. **Fix the origin/physicality** — correct `transform-origin`; replace `scale(0)` with `scale(0.95)`+opacity.
+5. **Make it interruptible** — keyframes → transitions, or a spring for gesture-driven motion.
+6. **Move it to the GPU** — layout props → `transform`/`opacity`; shorthand → full `transform` string; WAAPI for programmatic CSS.
+7. **Asymmetric timing** — slow the deliberate phase, snap the response.
+8. **Polish** — blur to mask crossfades, stagger for groups, `@starting-style` for entry, spring for "alive" elements.
+9. **Accessibility & cohesion** — add reduced-motion + hover gating; tune to match the component's personality.
+
+## Required Output Format
+
+Two parts, in this order.
+
+### Part 1 — Findings table (REQUIRED)
+
+A single markdown table. One row per issue. Never a "Before:/After:" list.
+
+| Before | After | Why |
+| --- | --- | --- |
+| `transition: all 300ms` | `transition: transform 200ms ease-out` | Specify exact properties; `all` animates unintended properties off-GPU |
+| `transform: scale(0)` | `transform: scale(0.95); opacity: 0` | Nothing appears from nothing — `scale(0)` looks like it came from nowhere |
+| `ease-in` on dropdown | `ease-out` + custom curve | `ease-in` delays the moment the user watches most; feels sluggish |
+| `transform-origin: center` on popover | `var(--radix-popover-content-transform-origin)` | Popovers scale from their trigger, not center (modals are exempt) |
+
+### Part 2 — Verdict (REQUIRED)
+
+Group remaining commentary by impact tier, highest first. Omit empty tiers.
+
+1. **Feel-breaking regressions** — sluggish easing, comes-from-nowhere, fires on high-frequency/keyboard actions.
+2. **Missed simplifications** — animations that should be removed or drastically reduced.
+3. **Performance** — non-GPU properties, dropped-frame risks, recalc storms.
+4. **Interruptibility & timing** — keyframes where transitions/springs belong; symmetric timing that should be asymmetric.
+5. **Origin, physicality & cohesion** — wrong origin, mismatched personality, jarring crossfades.
+6. **Accessibility** — reduced-motion and pointer/hover gating.
+
+Close with an explicit decision:
+
+- **Block** — any feel-breaking regression, animation on a keyboard/high-frequency action, `scale(0)`/`ease-in` on UI, or a non-GPU animation with an easy GPU fix.
+- **Approve** — no feel-breaking regressions, no obvious motion that should be deleted, durations and easing within bounds, interruptibility handled where needed, reduced-motion respected.
+
+Be specific and cite `file:line`. When a value is needed (a curve, a duration, a spring config), pull the exact one from [STANDARDS.md](STANDARDS.md) rather than approximating.
+
+## Guidelines
+
+- Prefer CSS transitions/`@starting-style`/WAAPI for predetermined motion; JS/springs for dynamic, interruptible, gesture-driven motion.
+- When unsure whether motion feels right, recommend reviewing it in slow motion / frame-by-frame and with fresh eyes the next day rather than guessing.
diff --git a/.cursor/skills/review-animations/STANDARDS.md b/.cursor/skills/review-animations/STANDARDS.md
new file mode 100644
index 000000000..b6dc9b19a
--- /dev/null
+++ b/.cursor/skills/review-animations/STANDARDS.md
@@ -0,0 +1,188 @@
+# Animation Standards Reference
+
+The precise values, curves, and rules behind the review. Cite these in findings instead of approximating. Distilled from Emil Kowalski's design engineering philosophy ([animations.dev](https://animations.dev/)).
+
+## Should it animate? (frequency table)
+
+| Frequency | Decision |
+| --- | --- |
+| 100+ times/day (keyboard shortcuts, command palette toggle) | No animation. Ever. |
+| Tens of times/day (hover effects, list navigation) | Remove or drastically reduce |
+| Occasional (modals, drawers, toasts) | Standard animation |
+| Rare / first-time (onboarding, feedback, celebrations) | Can add delight |
+
+**Never animate keyboard-initiated actions** — they repeat hundreds of times daily; animation makes them feel slow and disconnected. (Raycast has no open/close animation — correct for something used hundreds of times a day.)
+
+Valid purposes for motion: spatial consistency, state indication, explanation, feedback, preventing jarring change. "It looks cool" on a frequently-seen element is not valid.
+
+## Easing
+
+Decision order:
+- Entering or exiting → **`ease-out`** (starts fast, feels responsive)
+- Moving / morphing on screen → **`ease-in-out`**
+- Hover / color change → **`ease`**
+- Constant motion (marquee, progress) → **`linear`**
+- Default → **`ease-out`**
+
+**Never `ease-in` on UI.** It starts slow, delaying the exact moment the user is watching. `ease-out` at 200ms *feels* faster than `ease-in` at 200ms.
+
+Built-in CSS easings are too weak. Use strong custom curves:
+
+```css
+--ease-out: cubic-bezier(0.23, 1, 0.32, 1); /* strong ease-out for UI */
+--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1); /* strong ease-in-out for on-screen movement */
+--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1); /* iOS-like drawer curve (Ionic) */
+```
+
+Find curves at [easing.dev](https://easing.dev/) or [easings.co](https://easings.co/) — don't hand-roll from scratch.
+
+## Duration
+
+| Element | Duration |
+| --- | --- |
+| Button press feedback | 100–160ms |
+| Tooltips, small popovers | 125–200ms |
+| Dropdowns, selects | 150–250ms |
+| Modals, drawers | 200–500ms |
+| Marketing / explanatory | Can be longer |
+
+**Rule: UI animations stay under 300ms.** A 180ms dropdown feels more responsive than a 400ms one. Faster spinners make load feel faster (same actual time). Instant tooltips after the first (skip delay + animation) make a toolbar feel faster.
+
+## Physicality
+
+- **Never `scale(0)`.** Start from `scale(0.9–0.97)` + `opacity: 0`. Nothing in the real world appears from nothing.
+- **Origin-aware popovers.** Scale from the trigger, not center:
+ ```css
+ .popover { transform-origin: var(--radix-popover-content-transform-origin); } /* Radix */
+ .popover { transform-origin: var(--transform-origin); } /* Base UI */
+ ```
+ **Modals are exempt** — they appear centered in the viewport, keep `transform-origin: center`.
+- **Button press feedback.** `transform: scale(0.97)` on `:active`, `transition: transform 160ms ease-out`. Subtle (0.95–0.98). Applies to any pressable element.
+
+## Springs
+
+Feel natural because they simulate physics; no fixed duration — they settle on parameters. Use for: drag with momentum, "alive" elements (Dynamic Island), interruptible gestures, decorative mouse-tracking.
+
+```js
+// Apple-style (easier to reason about) — recommended
+{ type: "spring", duration: 0.5, bounce: 0.2 }
+
+// Traditional physics (more control)
+{ type: "spring", mass: 1, stiffness: 100, damping: 10 }
+```
+
+Keep bounce subtle (0.1–0.3); avoid bounce in most UI — reserve for drag-to-dismiss and playful interactions. Springs maintain velocity when interrupted (keyframes restart from zero), so they're ideal for gestures users may reverse mid-motion.
+
+Mouse interactions: interpolate with `useSpring` rather than tying value directly to mouse position (direct = artificial, no momentum). Only do this when the motion is decorative.
+
+## Interruptibility
+
+CSS **transitions** can be interrupted and retargeted mid-animation; **keyframes** restart from zero. For anything triggered rapidly (toasts being added, toggles), transitions are smoother.
+
+```css
+/* Interruptible — good for dynamic UI */
+.toast { transition: transform 400ms ease; }
+
+/* Not interruptible — avoid for dynamic UI */
+@keyframes slideIn { from { transform: translateY(100%); } to { transform: translateY(0); } }
+```
+
+Use `@starting-style` for entry without JS:
+
+```css
+.toast {
+ opacity: 1; transform: translateY(0);
+ transition: opacity 400ms ease, transform 400ms ease;
+ @starting-style { opacity: 0; transform: translateY(100%); }
+}
+```
+
+Legacy fallback: `useEffect(() => setMounted(true), [])` + `data-mounted` attribute.
+
+## Asymmetric timing
+
+Slow where the user is deciding, fast where the system responds.
+
+```css
+.overlay { transition: clip-path 200ms ease-out; } /* release: fast */
+.button:active .overlay { transition: clip-path 2s linear; } /* press: slow, deliberate */
+```
+
+## Performance
+
+- **Only animate `transform` and `opacity`** — they skip layout/paint and run on the GPU. `padding`/`margin`/`height`/`width`/`top`/`left` trigger all three rendering steps.
+- **Don't drive child transforms via a CSS variable on the parent** — it recalcs styles for all children. Set `transform` directly on the element.
+ ```js
+ element.style.setProperty('--swipe-amount', `${d}px`); // bad: recalc on all children
+ element.style.transform = `translateY(${d}px)`; // good: only this element
+ ```
+- **Framer Motion shorthands are NOT hardware-accelerated.** `x`/`y`/`scale` run on the main thread via rAF and drop frames under load. Use the full transform string:
+ ```jsx
+
// drops frames under load
+
// hardware accelerated
+ ```
+- **CSS animations beat JS under load** — they run off the main thread; rAF-based animations stutter while the browser loads/scripts/paints. Use CSS for predetermined motion, JS for dynamic/interruptible.
+- **WAAPI** gives JS control with CSS performance (hardware-accelerated, interruptible, no library):
+ ```js
+ element.animate([{ clipPath: 'inset(0 0 100% 0)' }, { clipPath: 'inset(0 0 0 0)' }],
+ { duration: 1000, fill: 'forwards', easing: 'cubic-bezier(0.77, 0, 0.175, 1)' });
+ ```
+
+## Transforms & clip-path
+
+- **`translate` percentages** are relative to the element's own size — `translateY(100%)` moves by the element's height regardless of dimensions (how Sonner/Vaul position toasts/drawers). Prefer over hardcoded px.
+- **`scale()` scales children too** (font, icons, content) — a feature for press feedback.
+- **3D**: `rotateX/Y` + `transform-style: preserve-3d` for depth/orbit/flip without JS.
+- **`clip-path: inset(t r b l)`** is a powerful animation tool: each value eats in from that side. Uses: reveal-on-scroll (`inset(0 0 100% 0)` → `inset(0 0 0 0)`), hold-to-delete overlay, seamless tab color transitions (duplicate + clip the active copy), comparison sliders.
+
+## Gestures & drag
+
+- **Momentum dismissal**: don't require crossing a distance threshold — compute velocity (`Math.abs(distance)/elapsedMs`); dismiss if `> ~0.11`. A flick should be enough.
+- **Damping at boundaries**: dragging past a natural edge moves less the further you go (real things slow before stopping).
+- **Pointer capture** once dragging starts, so it continues when the pointer leaves bounds.
+- **Multi-touch protection**: ignore extra touch points after the drag begins (`if (isDragging) return`) — prevents jumps.
+- **Friction over hard stops** — allow over-drag with rising resistance rather than an invisible wall.
+
+## Masking imperfect crossfades
+
+When a crossfade shows two overlapping states despite tuning easing/duration, add subtle `filter: blur(2px)` during the transition to blend them into one perceived transformation. Keep blur < 20px (heavy blur is expensive, especially Safari).
+
+## Stagger
+
+Stagger group entrances; 30–80ms between items. Longer delays feel slow. Stagger is decorative — never block interaction while it plays.
+
+```css
+.item { opacity: 0; transform: translateY(8px); animation: fadeIn 300ms ease-out forwards; }
+.item:nth-child(2) { animation-delay: 50ms; }
+.item:nth-child(3) { animation-delay: 100ms; }
+@keyframes fadeIn { to { opacity: 1; transform: translateY(0); } }
+```
+
+## Accessibility
+
+```css
+@media (prefers-reduced-motion: reduce) {
+ .element { animation: fade 0.2s ease; } /* keep opacity/color, drop transform-based motion */
+}
+@media (hover: hover) and (pointer: fine) {
+ .element:hover { transform: scale(1.05); } /* gate hover motion — touch fires false hovers on tap */
+}
+```
+
+```jsx
+const reduce = useReducedMotion();
+const closedX = reduce ? 0 : '-100%';
+```
+
+Reduced motion means fewer and gentler animations, not zero — keep transitions that aid comprehension, remove movement/position changes.
+
+## Debugging (recommend in reviews when feel is uncertain)
+
+- **Slow motion**: bump duration 2–5× or use DevTools animation inspector. Check colors crossfade cleanly, easing doesn't stop abruptly, `transform-origin` is right, coordinated properties stay in sync.
+- **Frame-by-frame**: Chrome DevTools Animations panel reveals timing drift between coordinated properties.
+- **Real devices** for gestures (drawers, swipe) — connect a phone, hit the dev server by IP, use Safari remote devtools.
+- **Fresh eyes next day** — imperfections invisible during development surface later.
+
+## Cohesion
+
+Match motion to the component's personality: playful can be bouncier; a professional dashboard should be crisp and fast. Sonner feels right partly because easing, duration, design, and even the name are in harmony — slightly slower, `ease` rather than `ease-out`, to feel elegant. Opacity + height in entering/exiting lists is trial and error; there's no formula — adjust until it feels right.
diff --git a/.rules/ponytail.mdc b/.rules/ponytail.mdc
new file mode 100644
index 000000000..db435a75d
--- /dev/null
+++ b/.rules/ponytail.mdc
@@ -0,0 +1,36 @@
+---
+description: Ponytail, lazy senior dev mode. Always pick the simplest solution that works.
+globs:
+alwaysApply: true
+---
+
+# Ponytail, lazy senior dev mode
+
+You are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.
+
+Before writing any code, stop at the first rung that holds:
+
+1. Does this need to be built at all? (YAGNI)
+2. Does it already exist in this codebase? Reuse the helper, util, or pattern that's already here, don't re-write it.
+3. Does the standard library already do this? Use it.
+4. Does a native platform feature cover it? Use it.
+5. Does an already-installed dependency solve it? Use it.
+6. Can this be one line? Make it one line.
+7. Only then: write the minimum code that works.
+
+The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
+
+Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
+
+Rules:
+
+- No abstractions that weren't explicitly requested.
+- No new dependency if it can be avoided.
+- No boilerplate nobody asked for.
+- Deletion over addition. Boring over clever. Fewest files possible.
+- Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
+- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
+- Mark intentional simplifications with a `ponytail:` comment. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment names the ceiling and the upgrade path.
+
+Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test.
diff --git a/LICENSE b/LICENSE
index 261eeb9e9..b77a3077d 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,3 +1,18 @@
+Copyright (c) SurfSense
+
+Portions of this software are licensed as follows:
+
+* All content that resides under the "surfsense_backend/app/proprietary/"
+ directory of this repository is licensed under the Business Source License
+ 1.1 as defined in "surfsense_backend/app/proprietary/LICENSE".
+* All third-party components incorporated into the SurfSense software are
+ licensed under the original license provided by the owner of the applicable
+ component.
+* Content outside of the above-mentioned directory is available under the
+ Apache License, Version 2.0, as defined below.
+
+-----------------------------------------------------------------------------
+
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
diff --git a/README.es.md b/README.es.md
index ea7623617..82cfcae1d 100644
--- a/README.es.md
+++ b/README.es.md
@@ -1,4 +1,4 @@
-
+
@@ -20,289 +20,270 @@
