# Hover Video Preview ## Objective Hovering a video card plays a short silent clip so people see what it is before clicking. A silent, short-loop preview that plays inside a video card on deliberate hover and returns to the poster on exit. ## Before You Begin This feature is being added to an application that already exists and already works. Do not scaffold a new project, and do not assume a blank slate. Inspect the codebase first and establish: - The existing application structure and where code of this kind already lives. - The framework and version in use. - The existing design system — colours, spacing, typography, and component conventions. - Existing UI components you can reuse instead of writing new ones. - The existing database structure, if this feature needs to persist anything. - The existing authentication and authorization system, if this feature is user-scoped. - Dependencies already installed, so you don't add a library that duplicates one. - The existing test setup and conventions. Only start writing code once you understand the above. If the application already implements part of this feature, extend it rather than replacing it. ## Implementation Instructions 1. Generate a short, low-resolution, silent preview clip during video processing and store it alongside the poster frame. Do not play the full source file behind the card. 2. Require a deliberate hover before doing anything. Wait several hundred milliseconds after the pointer settles, then load, so a cursor crossing a grid does not fire a dozen requests. 3. Give touch devices an explicit preview control on the card, since hover does not exist there. A long-press or a small preview button is fine; silently doing nothing on mobile is not. 4. Keep the preview inside the card's existing reserved dimensions so nothing reflows. If the app has a Media Aspect Ratio System or Responsive Card Grid, honour those boxes rather than sizing the video independently. 5. Do not treat this as a substitute for Image Lightbox or the full player. It is a glance, not a viewing experience, and it must never take over the card's click target. ## UI and UX Requirements Match the application's existing design system exactly. Reuse its components, spacing, and typography. This feature should look like it was always there. ## Responsive Requirements Works on mobile, tablet, and desktop. Touch targets are large enough to hit on a phone, and nothing overflows horizontally at 320px. ## Accessibility Requirements - Fully keyboard navigable. - Correct semantic elements and ARIA roles. - Visible focus states. - Meets WCAG AA contrast. - Dynamic changes are announced to screen readers. - Respects prefers-reduced-motion. ## Edge Cases - A pointer passing over a grid on its way elsewhere must not start loading. Delay the start, and if the pointer leaves before the clip begins, abort the request rather than letting it complete and play into an empty card. - Cancel in-flight preview requests when the pointer leaves early. Without cancellation a fast scroll through a grid leaves a queue of downloads competing with the page's real content. - Cap how many previews may load or play at once. A dense grid that starts eight videos will saturate a mobile connection and stall everything else on the page. - Returning to the poster frame must be clean. A preview that ends on a random frame, freezes on the last one, or flickers as it swaps back makes the whole grid feel broken. - Respect the reduced-motion preference. If the app has Reduced Motion Support, hook into it and skip autoplay entirely, offering the preview only on an explicit click. - Previews must stay silent regardless of the video's own audio track, and must never trigger the browser's autoplay-with-sound block. - A video whose preview clip has not been generated yet, or failed to generate, must simply keep showing its poster with no error and no dead hover state. - Pausing previews when the tab is hidden or the card scrolls out of view avoids burning battery on video nobody is looking at. ## Testing Exercise the feature end to end in the running application. Cover every edge case above, then run the existing test suite and confirm nothing regressed. ## Acceptance Criteria - [ ] Hovering a card plays a short silent preview only after a deliberate delay. - [ ] Leaving early cancels the pending request and no preview appears. - [ ] Concurrent previews are capped so a grid does not saturate the connection. - [ ] Exiting a card returns cleanly to the poster frame with no flicker or frozen frame. - [ ] Touch devices get an explicit preview control instead of relying on hover. - [ ] Reduced-motion users get no autoplay. - [ ] Cards with no generated preview show their poster and behave normally. - [ ] The feature matches the existing design system. - [ ] No existing functionality is broken. ## Adaptation Rules - Match the existing design system. Do not introduce a new colour palette, spacing scale, or component library. - Reuse existing components and utilities wherever they fit. - Follow the naming, file layout, and code style already present. - Do not upgrade, replace, or remove existing dependencies to make this feature fit. Adapt the feature to the app, not the app to the feature. - Do not break existing functionality. If a change is genuinely required in existing code, make the smallest one that works and say so. - If something in these instructions conflicts with how the application is built, follow the application and explain the deviation. ## Final Verification Before you report the work as done: 1. Re-read the acceptance criteria above and check each one against what you actually built. 2. Run the application and exercise the feature end to end. 3. Run the existing test suite and confirm you have broken nothing. 4. Check the feature on mobile, tablet, and desktop widths. 5. Check keyboard navigation and focus handling. 6. Summarize what changed: files added, files modified, and anything you deliberately did differently because of how this application is built. If any acceptance criterion is unmet, fix it before reporting completion.