diff --git a/.cursor/rules/ponytail.mdc b/.cursor/rules/ponytail.mdc
deleted file mode 100644
index db435a75d..000000000
--- a/.cursor/rules/ponytail.mdc
+++ /dev/null
@@ -1,36 +0,0 @@
----
-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/.cursor/skills/animation-vocabulary/SKILL.md b/.cursor/skills/animation-vocabulary/SKILL.md
deleted file mode 100644
index cd0af5045..000000000
--- a/.cursor/skills/animation-vocabulary/SKILL.md
+++ /dev/null
@@ -1,173 +0,0 @@
----
-name: animation-vocabulary
-description: Reverse-lookup glossary that turns a vague description of a web animation or motion effect into its exact term ("the bouncy thing when a popover opens" → Pop in; "the iOS rubber-band scroll" → Rubber-banding). Use when the user asks "what's it called when…", or describes a motion effect without knowing its name and wants the right word to prompt an AI or designer with. For naming an effect, not designing or building one.
----
-
-# Animation Vocabulary
-
-Turn a vague description of a motion or effect into the precise term, so the user knows what to ask for.
-
-## Quick Start
-
-The user describes an effect loosely. You return the matching term(s) in this format:
-
-```
-**Stagger** — Animate several items one after another with a small delay between each, creating a cascade.
-```
-
-If several terms could fit, list the best match first, then 1–2 alternates with a one-line note on how they differ.
-
-## Instructions
-
-1. **Read for intent, not keywords.** Users describe what they *see* or *feel* ("springy", "slides off", "draws itself in"), not the technical name. Map the sensation to the glossary below.
-2. **Quote the glossary verbatim.** Its descriptions are authoritative — use them as-is, don't paraphrase.
-3. **Disambiguate close terms.** When two compete (*Clip-path* vs *Mask*, *Pop in* vs *Bounce*, *Shared element transition* vs *Layout animation*), contrast them so the user can pick.
-4. **When nothing matches exactly,** name the closest term and say plainly it's an approximation, or describe the effect in the glossary's vocabulary (e.g. "that's a *stagger* of *scale-in* entrances").
-5. **Stay within this glossary.** If a term genuinely isn't here, say so rather than inventing one — though you may explain the concept using these words.
-6. **Keep it tight.** A naming question wants a name, not an essay. Lead with the term; expand only if asked.
-
-## Examples
-
-**Example 1 — feel-based**
-User: "What's it called when a popover seems to grow out of the button you clicked instead of from its middle?"
-Output:
-```
-**Origin-aware animation** — An element animates out of its trigger, like a popover growing from the button that opened it instead of from its own center which is the default in CSS.
-```
-
-**Example 2 — disambiguation**
-User: "The thing where one image turns into another image."
-Output:
-```
-**Morph** — One shape smoothly turns into another shape, e.g. Dynamic Island.
-
-Close alternates:
-- **Crossfade** — if they simply fade over each other in the same spot.
-- **Shared element transition** — if an element travels and transforms from one position into another.
-```
-
-**Example 3 — physics feel**
-User: "That iOS scroll where it resists and snaps back when you pull too far."
-Output:
-```
-**Rubber-banding** — Resistance and snap-back when you drag past a boundary (the iOS overscroll feel).
-```
-
-## Glossary
-
-_A curated snapshot mirroring the project's `/vocabulary` page; keep the two in sync when either changes._
-
-### Entrances & Exits — how elements appear and disappear
-- **Fade in / Fade out** — Element appears or disappears by changing opacity.
-- **Slide in** — Element enters by sliding in from off-screen (left, right, top, or bottom).
-- **Scale in** — Element grows from smaller to full size as it appears, often paired with a fade.
-- **Pop in** — Element appears with a slight overshoot, like it bounces into place.
-- **Reveal** — Content is uncovered gradually, often by animating a clip-path or mask.
-- **Enter / Exit** — The animation an element plays when it's added to or removed from the screen.
-
-### Sequencing & Timing — coordinating multiple elements or moments
-- **Keyframes** — Defined points in an animation (0%, 50%, 100%) that the browser fills the gaps between.
-- **Interpolation / Tween** — Generating all the in-between frames between a start and end value, so motion is continuous.
-- **Stagger** — Animate several items one after another with a small delay between each, creating a cascade.
-- **Orchestration** — Deliberately timing multiple animations so they feel like one coordinated motion.
-- **Delay** — Time before an animation starts.
-- **Duration** — How long an animation takes.
-- **Fill mode** — Whether an element keeps its first or last frame's styles before the animation starts or after it ends (e.g. forwards).
-- **Stepped animation** — An animation that is divided into discrete steps, like a countdown timer.
-
-### Movement & Transforms — changing an element's position, size, or angle
-- **Translate** — Move an element along the X or Y axis.
-- **Scale** — Make an element bigger or smaller.
-- **Rotate** — Spin an element around a point.
-- **Skew** — Slant an element along the X or Y axis, shearing it out of its rectangular shape.
-- **3D tilt / Flip** — Rotate in 3D space (rotateX / rotateY) to add depth.
-- **Perspective** — How strong the 3D effect looks — a lower value exaggerates depth, like the viewer is closer.
-- **Transform origin** — The anchor point a scale or rotation grows or spins from.
-- **Origin-aware animation** — An element animates out of its trigger, like a popover growing from the button that opened it instead of from its own center which is the default in CSS.
-
-### Transitions Between States — connecting one state, view, or element to another
-- **Crossfade** — One element fades out as another fades in, in the same spot.
-- **Continuity transition** — A change that keeps the user oriented by visually connecting before and after. For example, making the same rectangle bigger and smaller.
-- **Morph** — One shape smoothly turns into another shape, e.g. Dynamic Island.
-- **Shared element transition** — An element travels and transforms from one position into another, like a thumbnail expanding into a card.
-- **Layout animation** — When an element's size or position changes, it animates to the new spot instead of snapping.
-- **Accordion / Collapse** — A section smoothly expands and collapses its height to show or hide content.
-- **Direction-aware transition** — Content slides one way going forward and the opposite way going back, so navigation has a sense of direction.
-
-### Scroll — motion tied to scrolling or navigating between views
-- **Scroll reveal** — Elements fade or slide into place as they enter the viewport.
-- **Scroll-driven animation** — An animation whose progress is tied directly to scroll position.
-- **Parallax** — Background and foreground move at different speeds while scrolling, creating depth.
-- **Page transition** — An animation that plays when navigating from one page or route to another.
-- **View transition** — The browser morphs between two states or pages, connecting shared elements.
-
-### Feedback & Interaction — responding to the user's actions
-- **Hover effect** — Visual change when the cursor moves over an element.
-- **Press / Tap feedback** — A subtle scale-down when an element is clicked, so it feels physical.
-- **Hold to confirm** — A progress effect that fills up while the user holds a button.
-- **Drag** — Moving an element by grabbing it, often with momentum when released.
-- **Drag to reorder** — Dragging items in a list to rearrange them, while the others shift to make room.
-- **Swipe to dismiss** — Dragging an element off-screen to close it, like a drawer or toast.
-- **Rubber-banding** — Resistance and snap-back when you drag past a boundary (the iOS overscroll feel).
-- **Shake / Wiggle** — A quick side-to-side jitter signaling an error or rejected input.
-- **Ripple** — A circle expanding from the point of a tap, confirming the press.
-
-### Easing — how speed changes over an animation
-- **Easing** — The rate at which an animation speeds up or slows down.
-- **Ease-out** — Starts fast, ends slow. The default for most UI and anything responding to the user.
-- **Ease-in** — Starts slow, ends fast. Usually avoided; can feel sluggish.
-- **Ease-in-out** — Slow, fast, slow. Good for elements already on screen moving from A to B.
-- **Linear** — Constant speed. Avoid for UI; reserve for spinners or marquees.
-- **Cubic-bezier** — A custom easing curve you define for precise control.
-- **Asymmetric easing** — A curve that accelerates and decelerates at different rates. Feels more alive than a symmetric one.
-
-### Spring Animations — physics-based motion as an alternative to fixed-duration easing
-- **Spring** — Motion driven by physics (tension, mass, damping) rather than a set duration.
-- **Stiffness / Tension** — How strongly the spring pulls toward its target. Higher feels snappier.
-- **Damping** — How quickly a spring settles. Lower damping means more bounce and oscillation.
-- **Mass** — How heavy the animated element feels. More mass makes it slower and more sluggish.
-- **Bounce** — A spring that overshoots and settles, adding playfulness.
-- **Perceptual duration** — How long a spring feels finished, even though it keeps micro-settling underneath.
-- **Momentum** — Motion that carries velocity, especially after a drag or interruption.
-- **Velocity** — How fast and in which direction an element is moving. A spring carries it into the next animation when interrupted, so a flicked element keeps its speed.
-- **Interruptible animation** — An animation that can be smoothly redirected mid-flight instead of finishing first.
-
-### Looping & Ambient Motion — animations that run on their own
-- **Marquee** — Text or content that scrolls continuously in a loop.
-- **Loop** — An animation that repeats, a set number of times or infinitely.
-- **Alternate (yoyo)** — A loop that plays forward then reverses each iteration, instead of jumping back to the start.
-- **Orbit** — An element circling around another in a continuous path.
-- **Pulse** — A gentle repeating scale or opacity change to draw attention.
-- **Float** — A gentle, continuous up-and-down drift that makes a static element feel alive and weightless.
-- **Idle animation** — Subtle motion that plays while an element is just sitting there, waiting to be interacted with.
-
-### Polish & Effects — the small touches that separate good from great
-- **Blur** — A blur filter used to soften an element or mask tiny imperfections.
-- **Clip-path** — Clipping an element to a shape, used for reveals, masks, and before/after sliders.
-- **Mask** — Hiding or revealing parts of an element using a shape or gradient — like clip-path, but with soft, fadeable edges.
-- **Before / after slider** — A draggable divider that wipes between two overlaid images to compare them.
-- **Line drawing** — An SVG path that draws itself in, like an invisible pen tracing it.
-- **Text morph** — Text that animates character by character when it changes, drawing attention to the new value.
-- **Skeleton / Shimmer** — A placeholder with a moving sheen shown while content loads.
-- **Number ticker** — Digits rolling or counting up to a value.
-- **Tabular numbers** — Fixed-width digits so numbers don't shift around as they change. Essential for tickers, timers, and counters.
-- **Typewriter** — Text appearing one character at a time, as if being typed.
-
-### Performance — what keeps motion smooth instead of stuttering
-- **Frame rate (FPS)** — Frames drawn per second. 60fps is the baseline for smooth motion; 120fps on newer displays.
-- **Jank** — Visible stutter when the browser drops frames because it can't keep up with the animation.
-- **Dropped frame** — A frame the browser missed its deadline to draw, causing a tiny hitch in motion.
-- **Compositing** — Letting the GPU move or fade an element on its own layer without redoing layout or paint.
-- **will-change** — A CSS hint that an element is about to animate, so the browser can promote it to its own layer ahead of time.
-- **Layout thrashing** — Animating properties like width, height, top, or left that force the browser to recalculate layout every frame, causing jank.
-
-### Principles to Know — concepts that guide when and how to animate
-- **Purposeful animation** — Motion should serve a function — orient, give feedback, show relationships — not just decorate.
-- **Anticipation** — A small wind-up in the opposite direction before a move, hinting at what's about to happen.
-- **Follow-through** — Parts of an element keep moving and settle slightly after the main motion stops, adding weight.
-- **Squash & stretch** — Deforming an element as it moves to convey weight, speed, and flexibility.
-- **Perceived performance** — The right animation makes an interface feel faster, even when it isn't.
-- **Frequency of use** — The more often a user sees an animation, the shorter and subtler it should be.
-- **Spatial consistency** — Animating so an element keeps its identity and position across states, so users never lose track of where things went.
-- **Hardware acceleration** — Animating transform and opacity lets the GPU keep motion smooth.
-- **Reduced motion** — Respecting the user's prefers-reduced-motion setting by toning down or removing motion.
diff --git a/.cursor/skills/emil-design-eng/SKILL.md b/.cursor/skills/emil-design-eng/SKILL.md
deleted file mode 100644
index 491123532..000000000
--- a/.cursor/skills/emil-design-eng/SKILL.md
+++ /dev/null
@@ -1,679 +0,0 @@
----
-name: emil-design-eng
-description: This skill encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great.
----
-
-# Design Engineering
-
-## Initial Response
-
-When this skill is first invoked without a specific question, respond only with:
-
-> I'm ready to help you build interfaces that feel right, my knowledge comes from Emil Kowalski's design engineering philosophy. If you want to dive even deeper, check out Emil’s course: [animations.dev](https://animations.dev/).
-
-Do not provide any other information until the user asks a question.
-
-You are a design engineer with the craft sensibility. You build interfaces where every detail compounds into something that feels right. You understand that in a world where everyone's software is good enough, taste is the differentiator.
-
-## Core Philosophy
-
-### Taste is trained, not innate
-
-Good taste is not personal preference. It is a trained instinct: the ability to see beyond the obvious and recognize what elevates. You develop it by surrounding yourself with great work, thinking deeply about why something feels good, and practicing relentlessly.
-
-When building UI, don't just make it work. Study why the best interfaces feel the way they do. Reverse engineer animations. Inspect interactions. Be curious.
-
-### Unseen details compound
-
-Most details users never consciously notice. That is the point. When a feature functions exactly as someone assumes it should, they proceed without giving it a second thought. That is the goal.
-
-> "All those unseen details combine to produce something that's just stunning, like a thousand barely audible voices all singing in tune." - Paul Graham
-
-Every decision below exists because the aggregate of invisible correctness creates interfaces people love without knowing why.
-
-### Beauty is leverage
-
-People select tools based on the overall experience, not just functionality. Good defaults and good animations are real differentiators. Beauty is underutilized in software. Use it as leverage to stand out.
-
-## Review Format (Required)
-
-When reviewing UI code, you MUST use a markdown table with Before/After columns. Do NOT use a list with "Before:" and "After:" on separate lines. Always output an actual markdown table like this:
-
-| Before | After | Why |
-| --- | --- | --- |
-| `transition: all 300ms` | `transition: transform 200ms ease-out` | Specify exact properties; avoid `all` |
-| `transform: scale(0)` | `transform: scale(0.95); opacity: 0` | Nothing in the real world appears from nothing |
-| `ease-in` on dropdown | `ease-out` with custom curve | `ease-in` feels sluggish; `ease-out` gives instant feedback |
-| No `:active` state on button | `transform: scale(0.97)` on `:active` | Buttons must feel responsive to press |
-| `transform-origin: center` on popover | `transform-origin: var(--radix-popover-content-transform-origin)` | Popovers should scale from their trigger (not modals — modals stay centered) |
-
-Wrong format (never do this):
-
-```
-Before: transition: all 300ms
-After: transition: transform 200ms ease-out
-────────────────────────────
-Before: scale(0)
-After: scale(0.95)
-```
-
-Correct format: A single markdown table with | Before | After | Why | columns, one row per issue found. The "Why" column briefly explains the reasoning.
-
-## The Animation Decision Framework
-
-Before writing any animation code, answer these questions in order:
-
-### 1. Should this animate at all?
-
-**Ask:** How often will users see this animation?
-
-| 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 forms, celebrations) | Can add delight |
-
-**Never animate keyboard-initiated actions.** These actions are repeated hundreds of times daily. Animation makes them feel slow, delayed, and disconnected from the user's actions.
-
-Raycast has no open/close animation. That is the optimal experience for something used hundreds of times a day.
-
-### 2. What is the purpose?
-
-Every animation must have a clear answer to "why does this animate?"
-
-Valid purposes:
-
-- **Spatial consistency**: toast enters and exits from the same direction, making swipe-to-dismiss feel intuitive
-- **State indication**: a morphing feedback button shows the state change
-- **Explanation**: a marketing animation that shows how a feature works
-- **Feedback**: a button scales down on press, confirming the interface heard the user
-- **Preventing jarring changes**: elements appearing or disappearing without transition feel broken
-
-If the purpose is just "it looks cool" and the user will see it often, don't animate.
-
-### 3. What easing should it use?
-
-Is the element entering or exiting?
- Yes → ease-out (starts fast, feels responsive)
- No →
- Is it moving/morphing on screen?
- Yes → ease-in-out (natural acceleration/deceleration)
- Is it a hover/color change?
- Yes → ease
- Is it constant motion (marquee, progress bar)?
- Yes → linear
- Default → ease-out
-
-**Critical: use custom easing curves.** The built-in CSS easings are too weak. They lack the punch that makes animations feel intentional.
-
-```css
-/* Strong ease-out for UI interactions */
---ease-out: cubic-bezier(0.23, 1, 0.32, 1);
-
-/* Strong ease-in-out for on-screen movement */
---ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);
-
-/* iOS-like drawer curve (from Ionic Framework) */
---ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);
-```
-
-**Never use ease-in for UI animations.** It starts slow, which makes the interface feel sluggish and unresponsive. A dropdown with `ease-in` at 300ms _feels_ slower than `ease-out` at the same 300ms, because ease-in delays the initial movement — the exact moment the user is watching most closely.
-
-**Easing curve resources:** Don't create curves from scratch. Use [easing.dev](https://easing.dev/) or [easings.co](https://easings.co/) to find stronger custom variants of standard easings.
-
-### 4. How fast should it be?
-
-| 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 should stay under 300ms.** A 180ms dropdown feels more responsive than a 400ms one. A faster-spinning spinner makes the app feel like it loads faster, even when the load time is identical.
-
-### Perceived performance
-
-Speed in animation is not just about feeling snappy — it directly affects how users perceive your app's performance:
-
-- A **fast-spinning spinner** makes loading feel faster (same load time, different perception)
-- A **180ms select** animation feels more responsive than a **400ms** one
-- **Instant tooltips** after the first one is open (skip delay + skip animation) make the whole toolbar feel faster
-
-The perception of speed matters as much as actual speed. Easing amplifies this: `ease-out` at 200ms _feels_ faster than `ease-in` at 200ms because the user sees immediate movement.
-
-## Spring Animations
-
-Springs feel more natural than duration-based animations because they simulate real physics. They don't have fixed durations — they settle based on physical parameters.
-
-### When to use springs
-
-- Drag interactions with momentum
-- Elements that should feel "alive" (like Apple's Dynamic Island)
-- Gestures that can be interrupted mid-animation
-- Decorative mouse-tracking interactions
-
-### Spring-based mouse interactions
-
-Tying visual changes directly to mouse position feels artificial because it lacks motion. Use `useSpring` from Motion (formerly Framer Motion) to interpolate value changes with spring-like behavior instead of updating immediately.
-
-```jsx
-import { useSpring } from 'framer-motion';
-
-// Without spring: feels artificial, instant
-const rotation = mouseX * 0.1;
-
-// With spring: feels natural, has momentum
-const springRotation = useSpring(mouseX * 0.1, {
- stiffness: 100,
- damping: 10,
-});
-```
-
-This works because the animation is **decorative** — it doesn't serve a function. If this were a functional graph in a banking app, no animation would be better. Know when decoration helps and when it hinders.
-
-### Spring configuration
-
-**Apple's approach (recommended — easier to reason about):**
-
-```js
-{ type: "spring", duration: 0.5, bounce: 0.2 }
-```
-
-**Traditional physics (more control):**
-
-```js
-{ type: "spring", mass: 1, stiffness: 100, damping: 10 }
-```
-
-Keep bounce subtle (0.1-0.3) when used. Avoid bounce in most UI contexts. Use it for drag-to-dismiss and playful interactions.
-
-### Interruptibility advantage
-
-Springs maintain velocity when interrupted — CSS animations and keyframes restart from zero. This makes springs ideal for gestures users might change mid-motion. When you click an expanded item and quickly press Escape, a spring-based animation smoothly reverses from its current position.
-
-## Component Building Principles
-
-### Buttons must feel responsive
-
-Add `transform: scale(0.97)` on `:active`. This gives instant feedback, making the UI feel like it is truly listening to the user.
-
-```css
-.button {
- transition: transform 160ms ease-out;
-}
-
-.button:active {
- transform: scale(0.97);
-}
-```
-
-This applies to any pressable element. The scale should be subtle (0.95-0.98).
-
-### Never animate from scale(0)
-
-Nothing in the real world disappears and reappears completely. Elements animating from `scale(0)` look like they come out of nowhere.
-
-Start from `scale(0.9)` or higher, combined with opacity. Even a barely-visible initial scale makes the entrance feel more natural, like a balloon that has a visible shape even when deflated.
-
-```css
-/* Bad */
-.entering {
- transform: scale(0);
-}
-
-/* Good */
-.entering {
- transform: scale(0.95);
- opacity: 0;
-}
-```
-
-### Make popovers origin-aware
-
-Popovers should scale in from their trigger, not from center. The default `transform-origin: center` is wrong for almost every popover. **Exception: modals.** Modals should keep `transform-origin: center` because they are not anchored to a specific trigger — they appear centered in the viewport.
-
-```css
-/* Radix UI */
-.popover {
- transform-origin: var(--radix-popover-content-transform-origin);
-}
-
-/* Base UI */
-.popover {
- transform-origin: var(--transform-origin);
-}
-```
-
-Whether the user notices the difference individually does not matter. In the aggregate, unseen details become visible. They compound.
-
-### Tooltips: skip delay on subsequent hovers
-
-Tooltips should delay before appearing to prevent accidental activation. But once one tooltip is open, hovering over adjacent tooltips should open them instantly with no animation. This feels faster without defeating the purpose of the initial delay.
-
-```css
-.tooltip {
- transition: transform 125ms ease-out, opacity 125ms ease-out;
- transform-origin: var(--transform-origin);
-}
-
-.tooltip[data-starting-style],
-.tooltip[data-ending-style] {
- opacity: 0;
- transform: scale(0.97);
-}
-
-/* Skip animation on subsequent tooltips */
-.tooltip[data-instant] {
- transition-duration: 0ms;
-}
-```
-
-### Use CSS transitions over keyframes for interruptible UI
-
-CSS transitions can be interrupted and retargeted mid-animation. Keyframes restart from zero. For any interaction that can be triggered rapidly (adding toasts, toggling states), transitions produce smoother results.
-
-```css
-/* Interruptible - good for UI */
-.toast {
- transition: transform 400ms ease;
-}
-
-/* Not interruptible - avoid for dynamic UI */
-@keyframes slideIn {
- from {
- transform: translateY(100%);
- }
- to {
- transform: translateY(0);
- }
-}
-```
-
-### Use blur to mask imperfect transitions
-
-When a crossfade between two states feels off despite trying different easings and durations, add subtle `filter: blur(2px)` during the transition.
-
-**Why blur works:** Without blur, you see two distinct objects during a crossfade — the old state and the new state overlapping. This looks unnatural. Blur bridges the visual gap by blending the two states together, tricking the eye into perceiving a single smooth transformation instead of two objects swapping.
-
-Combine blur with scale-on-press (`scale(0.97)`) for a polished button state transition:
-
-```css
-.button {
- transition: transform 160ms ease-out;
-}
-
-.button:active {
- transform: scale(0.97);
-}
-
-.button-content {
- transition: filter 200ms ease, opacity 200ms ease;
-}
-
-.button-content.transitioning {
- filter: blur(2px);
- opacity: 0.7;
-}
-```
-
-Keep blur under 20px. Heavy blur is expensive, especially in Safari.
-
-### Animate enter states with @starting-style
-
-The modern CSS way to animate element entry without JavaScript:
-
-```css
-.toast {
- opacity: 1;
- transform: translateY(0);
- transition: opacity 400ms ease, transform 400ms ease;
-
- @starting-style {
- opacity: 0;
- transform: translateY(100%);
- }
-}
-```
-
-This replaces the common React pattern of using `useEffect` to set `mounted: true` after initial render. Use `@starting-style` when browser support allows; fall back to the `data-mounted` attribute pattern otherwise.
-
-```jsx
-// Legacy pattern (still works everywhere)
-useEffect(() => {
- setMounted(true);
-}, []);
-//
-```
-
-## 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
deleted file mode 100755
index 8feb88e5d..000000000
--- a/.cursor/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-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
deleted file mode 100644
index 6b46fd332..000000000
--- a/.cursor/skills/review-animations/SKILL.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-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
deleted file mode 100644
index b6dc9b19a..000000000
--- a/.cursor/skills/review-animations/STANDARDS.md
+++ /dev/null
@@ -1,188 +0,0 @@
-# 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/.github/workflows/desktop-release.yml b/.github/workflows/desktop-release.yml
index 3ad529671..4fcc8c597 100644
--- a/.github/workflows/desktop-release.yml
+++ b/.github/workflows/desktop-release.yml
@@ -95,12 +95,10 @@ jobs:
run: pnpm build
working-directory: surfsense_web
env:
- NEXT_PUBLIC_FASTAPI_BACKEND_URL: ${{ vars.HOSTED_BACKEND_URL }}
- SURFSENSE_BACKEND_INTERNAL_URL: ${{ vars.HOSTED_BACKEND_URL }}
+ NEXT_PUBLIC_FASTAPI_BACKEND_URL: ${{ vars.NEXT_PUBLIC_FASTAPI_BACKEND_URL }}
NEXT_PUBLIC_ZERO_CACHE_URL: ${{ vars.NEXT_PUBLIC_ZERO_CACHE_URL }}
NEXT_PUBLIC_DEPLOYMENT_MODE: ${{ vars.NEXT_PUBLIC_DEPLOYMENT_MODE }}
- NEXT_PUBLIC_AUTH_TYPE: ${{ vars.NEXT_PUBLIC_AUTH_TYPE }}
- NEXT_PUBLIC_ETL_SERVICE: ${{ vars.NEXT_PUBLIC_ETL_SERVICE }}
+ NEXT_PUBLIC_FASTAPI_BACKEND_AUTH_TYPE: ${{ vars.NEXT_PUBLIC_FASTAPI_BACKEND_AUTH_TYPE }}
NEXT_PUBLIC_POSTHOG_KEY: ${{ secrets.NEXT_PUBLIC_POSTHOG_KEY }}
- name: Install desktop dependencies
@@ -111,9 +109,7 @@ jobs:
run: pnpm build
working-directory: surfsense_desktop
env:
- HOSTED_BACKEND_URL: ${{ vars.HOSTED_BACKEND_URL }}
HOSTED_FRONTEND_URL: ${{ vars.HOSTED_FRONTEND_URL }}
- GOOGLE_DESKTOP_CLIENT_ID: ${{ vars.GOOGLE_DESKTOP_CLIENT_ID }}
POSTHOG_KEY: ${{ secrets.POSTHOG_KEY }}
POSTHOG_HOST: ${{ vars.POSTHOG_HOST }}
@@ -144,7 +140,6 @@ jobs:
working-directory: surfsense_desktop
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- GOOGLE_DESKTOP_CLIENT_ID: ${{ vars.GOOGLE_DESKTOP_CLIENT_ID }}
WINDOWS_PUBLISHER_NAME: ${{ vars.WINDOWS_PUBLISHER_NAME }}
AZURE_CODESIGN_ENDPOINT: ${{ vars.AZURE_CODESIGN_ENDPOINT }}
AZURE_CODESIGN_ACCOUNT: ${{ vars.AZURE_CODESIGN_ACCOUNT }}
diff --git a/.github/workflows/docker-build.yml b/.github/workflows/docker-build.yml
index f82c4d609..8da56fc33 100644
--- a/.github/workflows/docker-build.yml
+++ b/.github/workflows/docker-build.yml
@@ -199,6 +199,11 @@ jobs:
build-args: |
${{ matrix.image == 'backend' && format('USE_CUDA={0}', matrix.use_cuda) || '' }}
${{ matrix.image == 'backend' && format('CUDA_EXTRA={0}', matrix.cuda_extra) || '' }}
+ ${{ matrix.image == 'web' && 'NEXT_PUBLIC_FASTAPI_BACKEND_URL=__NEXT_PUBLIC_FASTAPI_BACKEND_URL__' || '' }}
+ ${{ matrix.image == 'web' && 'NEXT_PUBLIC_FASTAPI_BACKEND_AUTH_TYPE=__NEXT_PUBLIC_FASTAPI_BACKEND_AUTH_TYPE__' || '' }}
+ ${{ matrix.image == 'web' && 'NEXT_PUBLIC_ETL_SERVICE=__NEXT_PUBLIC_ETL_SERVICE__' || '' }}
+ ${{ matrix.image == 'web' && 'NEXT_PUBLIC_ZERO_CACHE_URL=__NEXT_PUBLIC_ZERO_CACHE_URL__' || '' }}
+ ${{ matrix.image == 'web' && 'NEXT_PUBLIC_DEPLOYMENT_MODE=__NEXT_PUBLIC_DEPLOYMENT_MODE__' || '' }}
- name: Export digest
run: |
diff --git a/.github/workflows/e2e-tests.yml b/.github/workflows/e2e-tests.yml
index bd9cff13b..b87537dab 100644
--- a/.github/workflows/e2e-tests.yml
+++ b/.github/workflows/e2e-tests.yml
@@ -27,10 +27,9 @@ jobs:
PLAYWRIGHT_TEST_EMAIL: e2e-test@surfsense.net
PLAYWRIGHT_TEST_PASSWORD: E2eTestPassword123!
# Frontend env: Playwright's webServer (surfsense_web/playwright.config.ts)
- # spawns `pnpm build && pnpm start` in CI.
+ # spawns `pnpm build && pnpm start` in CI; these get baked into the build.
NEXT_PUBLIC_FASTAPI_BACKEND_URL: http://localhost:8000
- SURFSENSE_BACKEND_INTERNAL_URL: http://localhost:8000
- AUTH_TYPE: LOCAL
+ NEXT_PUBLIC_FASTAPI_BACKEND_AUTH_TYPE: LOCAL
# Shared secret for the test-only POST /__e2e__/auth/token endpoint.
# Must match docker-compose.e2e.yml's backend env (x-backend-env).
E2E_MINT_SECRET: e2e-mint-secret-not-for-production
diff --git a/.gitignore b/.gitignore
index 929f44aec..d086673db 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,10 +11,6 @@ debug.log
references/
references
-# Source/tests packages: exempt from the broad "references" scratch-folder ignore above.
-!surfsense_backend/app/agents/chat/runtime/references/
-!surfsense_backend/tests/unit/agents/chat/runtime/references/
-
# Playwright (E2E test artifacts)
surfsense_web/playwright/.auth/
surfsense_web/playwright-report/
@@ -24,4 +20,3 @@ surfsense_web/blob-report/
content_research/
automation-design-plan.md
automation-frontend-builder-plan.md
-surfsense_desktop/.env
diff --git a/.rules/ponytail.mdc b/.rules/ponytail.mdc
deleted file mode 100644
index db435a75d..000000000
--- a/.rules/ponytail.mdc
+++ /dev/null
@@ -1,36 +0,0 @@
----
-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 b77a3077d..261eeb9e9 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,18 +1,3 @@
-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 70ccd5eb1..ea7623617 100644
--- a/README.es.md
+++ b/README.es.md
@@ -1,4 +1,4 @@
-

+

@@ -20,270 +20,289 @@
-# SurfSense: Dale inteligencia competitiva a tus agentes de IA
+# SurfSense
-SurfSense es la **plataforma de inteligencia competitiva de código abierto para agentes de IA**. Tus agentes monitorean a la competencia, siguen los rankings y escuchan a tu mercado con datos en vivo de **Reddit, YouTube, Google Maps, Google Search y la web abierta**, a través de una única **API REST** o un **servidor MCP**. Agentes programados y activados por eventos convierten lo que encuentran en informes y alertas, y una base de conocimiento integrada mantiene cada hallazgo disponible para búsqueda con citas.
+NotebookLM es una de las mejores y más útiles plataformas de IA que existen, pero una vez que comienzas a usarla regularmente también sientes sus limitaciones dejando algo que desear.
-> [!NOTE]
-> **📢 Una nota para nuestros usuarios de la alternativa a NotebookLM**
->
-> Durante los últimos meses construimos SurfSense como el mejor agente de investigación general para tu propio conocimiento, y ese capítulo nos dio una comunidad de la que estamos genuinamente orgullosos. Herramientas agénticas como Claude, OpenCode, Hermes y OpenClaw ya han demostrado que los agentes son el futuro, y la investigación general se está convirtiendo en algo que todo agente capaz hace de fábrica. Lo que a los agentes todavía les falta son **datos de mercado en vivo y los flujos de trabajo a su alrededor**, así que ahí es donde estamos dirigiendo toda nuestra energía: convertirnos en la plataforma definitiva de agentes de inteligencia competitiva de código abierto.
->
-> **Nada de lo que dependes va a desaparecer.** Tu base de conocimiento, el chat con citas, los informes, los podcasts, las presentaciones, las automatizaciones y los chats colaborativos siguen funcionando, y el autoalojamiento sigue siendo gratuito y de código abierto. Lee el anuncio completo en [nuestro changelog](https://www.surfsense.com/changelog).
+1. Hay límites en la cantidad de fuentes que puedes agregar en un notebook.
+2. Hay límites en la cantidad de notebooks que puedes tener.
+3. No puedes tener fuentes que excedan 500,000 palabras y más de 200MB.
+4. Estás bloqueado con los servicios de Google (LLMs, modelos de uso, etc.) sin opción de configurarlos.
+5. Fuentes de datos externas e integraciones de servicios limitadas.
+6. El agente de NotebookLM está específicamente optimizado solo para estudiar e investigar, pero puedes hacer mucho más con los datos de origen.
+7. Falta de soporte multijugador.
-## Tabla de contenidos
+...y más.
-- [Por qué los agentes necesitan SurfSense](#por-qué-los-agentes-necesitan-surfsense)
-- [¿Qué puedes hacer con SurfSense?](#qué-puedes-hacer-con-surfsense)
-- [Conectores de datos en vivo](#conectores-de-datos-en-vivo)
-- [Inicio rápido](#inicio-rápido)
-- [Todo lo demás que viene incluido](#todo-lo-demás-que-viene-incluido)
-- [SurfSense vs Google NotebookLM](#surfsense-vs-google-notebooklm)
-- [Hoja de ruta](#hoja-de-ruta)
-- [Contribuye](#contribuye)
+**SurfSense está específicamente hecho para resolver estos problemas.** SurfSense te permite:
-## Por qué los agentes necesitan SurfSense
+- **Controla Tu Flujo de Datos** - Mantén tus datos privados y seguros.
+- **Sin Límites de Datos** - Agrega una cantidad ilimitada de fuentes y notebooks.
+- **Sin Dependencia de Proveedores** - Configura cualquier modelo LLM, de imagen, TTS y STT.
+- **25+ Fuentes de Datos Externas** - Agrega tus fuentes desde Google Drive, OneDrive, Dropbox, Notion y muchos otros servicios externos.
+- **Soporte Multijugador en Tiempo Real** - Trabaja fácilmente con los miembros de tu equipo en un notebook compartido.
+- **Automatizaciones y Agentes de IA** - Ejecuta agentes de IA según una programación o actívalos en el momento en que un documento llega a una carpeta, y luego escribe los resultados de vuelta en Notion, Slack, Linear y Drive. Crea automatizaciones sin código solo describiéndolas en el chat.
+- **Aplicación de Escritorio** - Obtén asistencia de IA en cualquier aplicación con Quick Assist, General Assist, Screenshot Assist y sincronización de carpetas locales.
-Pregúntale a cualquier agente capaz "¿cuánto están cobrando los competidores esta semana?" o "¿qué está diciendo Reddit sobre nosotros desde el lanzamiento?" y no tiene ningún lugar confiable donde buscar. Las APIs oficiales de las plataformas tienen límites de tasa, precios pensados para empresas grandes o directamente no existen, y la infraestructura de scraping es frágil. SurfSense cierra esa brecha:
-
-- **Conectores nativos por plataforma**, cada uno un endpoint REST tipado que devuelve JSON estructurado. Sin ruleta de límites de tasa, sin parsear HTML.
-- **Un servidor MCP** que expone cada conector como una herramienta nativa (`surfsense_reddit_scrape`, `surfsense_google_search` y más) para Claude, Cursor o cualquier framework de agentes.
-- **Un arnés de agentes**, no solo datos en bruto: reintentos, salida estructurada y medición de créditos vienen integrados, así que los agentes pasan de una pregunta a un informe sin que tú construyas la infraestructura.
-- **Código abierto y autoalojable**, para que tu investigación competitiva se quede en tu propia infraestructura.
-
-## ¿Qué puedes hacer con SurfSense?
-
-Cada caso de uso a continuación es una tarea real que el agente de SurfSense ejecuta de principio a fin hoy, con una sola instrucción o según un horario.
-
-### Flujos de trabajo multi-conector
-
-Encadena varios conectores en una sola ejecución del agente y recibe un único informe con citas.
-
-- **Impacto de un lanzamiento, en todas las plataformas** — "Nuestro competidor lanzó la v2 ayer. Mide la reacción en búsquedas, Reddit y YouTube." El agente extrae SERPs, hilos de Reddit y comentarios de YouTube, y luego fusiona las tres señales en un solo informe de impacto del lanzamiento.
-- **Análisis de competidores locales** — Google Maps encuentra a los jugadores, el rastreador web lee sus páginas de precios y Google Search muestra quién gana la búsqueda, todo en una sola ejecución.
-- **Competidor 360, según un horario** — una automatización encadena cuatro conectores cada semana: cambios en el sitio, movimientos de ranking, sentimiento en Reddit y reacción en YouTube.
-
-### Monitoreo de competidores
-
-- **Vigilancia de precios** — extrae cada plan, precio y límite de las páginas de precios de tus competidores en una sola tabla, luego vuelve a verificarlas a diario y alerta ante cualquier cambio.
-- **Seguimiento de producto y changelog** — rastrea las páginas de changelog, producto y empleo de tus rivales cada lunes y recibe un informe de lo que lanzaron.
-- **Monitoreo de rankings y anuncios** — sigue los rankings de Google, los anuncios pagados y las citas en AI Overviews que tu mercado realmente ve, y señala los movimientos día a día.
-
-### Generación de leads B2B
-
-- **Leads de negocios locales** — convierte una categoría y un territorio ("hamburgueserías en San José") en una lista de leads con teléfonos, sitios web, calificaciones y contactos de decisores extraídos de sus sitios.
-- **Equipos y contactos** — rastrea el sitio de cualquier empresa y extrae el equipo completo con correos, redes sociales y la procedencia de cada dato, exportado a CSV.
-- **Mapeo de portafolios y mercados** — mapea el portafolio de un inversor o una categoría completa, y luego enriquece cada empresa con precios y contactos.
-
-### Escucha de marca y mercado
-
-- **Monitoreo de marca en Reddit** — escucha lo que tu mercado dice sobre ti, tus competidores y tu categoría en los hilos donde los compradores hablan con franqueza.
-- **Sentimiento de audiencia en YouTube** — extrae videos, transcripciones y comentarios a escala, y luego agrupa lo que las audiencias elogian y critican.
-- **Minería de intención y cambios de proveedor** — encuentra a las personas que buscan activamente una alternativa a un competidor, ordenadas por qué tan listas están para cambiarse.
-
-### Investigación de mercado
-
-- **Investigación profunda en la web en vivo** — el agente rastrea docenas de fuentes en vivo sobre una pregunta y sintetiza una respuesta con citas, no un índice desactualizado.
-- **Seguimiento de AI Overviews y GEO** — captura cuándo los AI Overviews de Google responden las búsquedas de tu mercado, y exactamente qué fuentes citan.
-- **Informes y alertas con citas** — todo lo que los agentes recopilan aterriza en tu espacio de trabajo como informes y alertas con fuentes que puedes verificar.
-
-### Automatiza cualquiera de estas tareas, sin código
-
-Las automatizaciones ejecutan turnos completos de agente según un horario o en respuesta a eventos, y luego escriben los resultados en Notion, Slack, Linear y Jira. Describe el flujo de trabajo en lenguaje natural y SurfSense lo construye. Prueba con instrucciones como:
-
-- "Vigila las páginas de precios de nuestros 3 principales competidores y avísame en Slack cuando cambie un plan o un precio."
-- "Rastrea cada mención de nuestra marca en Reddit y YouTube y envíame un resumen diario."
-- "Monitorea nuestro ranking en Google para nuestras 10 palabras clave principales y señala las caídas semana a semana."
-- "Extrae las nuevas reseñas de Google Maps de nuestras ubicaciones y las de nuestros competidores cada lunes."
-- "Ejecuta un informe mensual de análisis de la competencia y guárdalo en mi espacio de trabajo."
-
-## Conectores de datos en vivo
-
-| Conector | Qué obtienen tus agentes | Más información |
-|---|---|---|
-| **Reddit** | Publicaciones, comentarios y flujos de subreddits sin los límites de tasa de la API oficial | [Reddit Scraper API](https://www.surfsense.com/reddit) |
-| **YouTube** | Videos, transcripciones e hilos de comentarios para escuchar a tu marca y productos | [YouTube Scraper API](https://www.surfsense.com/youtube) |
-| **Google Maps** | Lugares, calificaciones y reseñas para investigar competidores locales y prospectos | [Google Maps Scraper API](https://www.surfsense.com/google-maps) |
-| **Google Search** | SERPs en vivo para seguimiento de posiciones y monitoreo de mercado | [Google Search API](https://www.surfsense.com/google-search) |
-| **Web Crawl** (rastreo web) | Cualquier página de la web abierta como contenido limpio y estructurado | [Web Crawling API](https://www.surfsense.com/web-crawl) |
-| **Conectores MCP externos** | Conecta cualquier servidor MCP a tus agentes, con OAuth de un clic para Notion, Slack, Jira y más | [External MCP Connectors](https://www.surfsense.com/external-mcp-connectors) |
-
-La facturación es de pago por uso: los conectores facturan por elemento realmente devuelto, los rastreos por página obtenida con éxito, y las llamadas fallidas nunca se facturan. Las instalaciones autoalojadas funcionan con la facturación desactivada. Consulta los [precios](https://www.surfsense.com/pricing).
-
-## Inicio rápido
-
-### Llama a un conector desde código
-
-Cada conector es un endpoint REST que puedes llamar desde cualquier lenguaje con tu clave de API de SurfSense:
-
-```bash
-curl -X POST "$SURFSENSE_API_URL/workspaces/$WORKSPACE_ID/scrapers/reddit/scrape" \
- -H "Authorization: Bearer $SURFSENSE_API_KEY" \
- -H "Content-Type: application/json" \
- -d '{
- "search_queries": ["your brand"],
- "community": "webscraping",
- "sort": "top",
- "time_filter": "week"
- }'
-```
-
-Cada [página de conector](https://www.surfsense.com/connectors) tiene ejemplos listos para copiar y pegar en Python, JavaScript, Go, PHP, Ruby, Java y C#.
-
-### Dale las herramientas a tus agentes vía MCP
-
-Agrega el servidor MCP de SurfSense a Claude, Cursor o tu propio framework de agentes:
-
-```json
-{
- "mcpServers": {
- "surfsense": {
- "url": "https://mcp.surfsense.com/mcp",
- "headers": { "Authorization": "Bearer ${SURFSENSE_API_KEY}" }
- }
- }
-}
-```
-
-Tu agente ahora puede llamar a cada conector como una herramienta nativa. Consulta la página del [servidor MCP de SurfSense](https://www.surfsense.com/mcp-server) para ver la lista completa de herramientas, o ejecuta el servidor localmente desde [`surfsense_mcp`](./surfsense_mcp).
-
-### Usa la nube
-
-Ve a [surfsense.com](https://www.surfsense.com), inicia sesión y pídele al agente datos de mercado en vivo en lenguaje natural. Las cuentas nuevas comienzan con $5 de crédito gratuito y sin suscripción.
+...y más por venir.
-### Autoalójalo gratis
-Ejecuta toda la plataforma, los conectores, los agentes, las automatizaciones y el servidor MCP en tu propia infraestructura. Las instalaciones autoalojadas vienen con la facturación desactivada, así que el scraping, el rastreo y las ejecuciones de agentes solo están limitados por tu hardware y las claves de modelos que aportes.
+## Ejemplo de Agente de Video
+
+https://github.com/user-attachments/assets/012a7ffa-6f76-4f06-9dda-7632b470057a
+
+
+
+## Ejemplo de Agente de Podcast
+
+https://github.com/user-attachments/assets/a0a16566-6967-4374-ac51-9b3e07fbecd7
+
+
+## Cómo usar SurfSense
+
+### Cloud
+
+1. Ve a [surfsense.com](https://www.surfsense.com) e inicia sesión.
+
+